From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EC0A3C36014 for ; Tue, 1 Apr 2025 15:46:48 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.934592.1336248 (Exim 4.92) (envelope-from ) id 1tzdou-0002fL-N8; Tue, 01 Apr 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 934592.1336248; Tue, 01 Apr 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 ) id 1tzdou-0002fE-Kd; Tue, 01 Apr 2025 15:46:32 +0000 Received: by outflank-mailman (input) for mailman id 934592; Tue, 01 Apr 2025 15:46:30 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tzdos-0002f8-Id for xen-devel@lists.xenproject.org; Tue, 01 Apr 2025 15:46:30 +0000 Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [2a00:1450:4864:20::52f]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 79ad3066-0f10-11f0-9ffb-bf95429c2676; Tue, 01 Apr 2025 17:46:28 +0200 (CEST) Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5e673822f76so9702359a12.2 for ; Tue, 01 Apr 2025 08:46:28 -0700 (PDT) Received: from [192.168.1.5] (user-109-243-64-225.play-internet.pl. [109.243.64.225]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5edc17dfd41sm7408007a12.73.2025.04.01.08.46.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Apr 2025 08:46:27 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 79ad3066-0f10-11f0-9ffb-bf95429c2676 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743522388; x=1744127188; 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=vIKjI1V1t2FTxepIuuZaGA4R4FaYVcgDVUe45kanUdQ=; b=NLPN8pgbz7W5me3YaqkdfmCAEZiC/IdJylkUrOmDx3lklIqx2jxYuiajlsUhRPo403 yzuRvqsglu+2U49dYtdx/WddwiFpp8qUd2z0nnrAOdeKHL/MsYsMVYIfwNPgU5p5bYJn 5/8P7Bo15WrUc0x10yFnAZcfItuMt3U/y12pTfBpVq9Lw36RSgRnPL+paqdQOeD+A9/L jJyKIcXEx2S2Ps34YXCLRsQhzBwRO2vTvudF6v9nGisTok4hhC137+Wmfc+CvpPAPtFt 24C9PsVjr2q+XnGh11JMMqGlMExyt7ViRF2EY0comdZKKd4kDeWHskdwFvtHKvYp5ATe okCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743522388; x=1744127188; 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=vIKjI1V1t2FTxepIuuZaGA4R4FaYVcgDVUe45kanUdQ=; b=jRPyZjX2PpVwR3TMc+6wb0CL7Lhlw4e1tfTKIRLqL2D4z8E6wb0jT03zlQihKWVEYj lSo9m1UZE3K56R9ACgqO1aT+Tu0khljvLXIZ4r1H4/pMX9Uizt7JTCXAQJ63q45aMVrC FhGxHWxEQvJOrOBI+siHwoFN45BkFyHmmQ++UwjTx4SqNCFAsnO5cFofDVE5+21h8jEL grmCzSDBJxcSYCO+vh4xUman7aPovAw+vBuOmQqsYH7WZosZPiYgTASTYSONS2fOfswP ZNCGjKX+qxQHU44s2mGXVRj3pup9g2BiznTjMP17tC0WyB5AqWxTdo6ND72dEuZTXcCb paPg== X-Forwarded-Encrypted: i=1; AJvYcCX71ibs3IQPjKli/oM9i/CWjN5poVzz5iDQ5xgRWZ4uqf/wdcutV7/mpMSK/EG0py1MDEJbyJWjYVU=@lists.xenproject.org X-Gm-Message-State: AOJu0YwkfhxtZQGYM9WKtgx9DPkstuxI4wJCvNyhUGAt174YT4M/LMmR jDi8xZ1eDDqrTRYxMtrr46EPUel+VgBsyttZoXH7o7Boz8uPLmTL X-Gm-Gg: ASbGncuo50dlgDnhcYDp/nbZRk3EYeDu583kgDY0dZXV4HlisF8K1779do/frAutzOM MLh4RucDzEk0Webaq1g3dG8VPVvQIfUfVNvAmv17D0YH3CojY9XlUv5tq+C8gnDWkPVNc9qMAfK alaTl78hQBn/HDnWjlvNHZBKYRZdBFixglN188M5iB5yEoUGy7z3zz3uyk3/6wFgSClHDBkXwSE 7K3HGgoGKMGe5V03rwrcqjdzESYiw5/kEE6TGg0rQu+97QjXYuGDpGAOVyUfM56DgqiR2FnctBs NypWcs30GJ3oN3zKxYYDveeHncuB/yHZi2O+qxGzrCOzRM1I8tPuPG8n4U4K4d8vG4JhHI/lEaX C5z+hhsyN8JLxImRIwA9h X-Google-Smtp-Source: AGHT+IGswNjWHPim6Ff1BZlJg9zBC287liKJLXY/6h9+2XymHc1KQz4Oqb+Z9Ay2TVOm2eEuWXOXYg== X-Received: by 2002:a05:6402:320e:b0:5ee:497:91f0 with SMTP id 4fb4d7f45d1cf-5ee049794d5mr11889465a12.34.1743522387498; Tue, 01 Apr 2025 08:46:27 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------UOzkySSbTXraRu17i4Ezn956" Message-ID: Date: Tue, 1 Apr 2025 17:46:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] xen/riscv: Increase XEN_VIRT_SIZE To: Julien Grall , Jan Beulich Cc: Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <54ebdcb7-071f-411f-803a-930dc330a497@suse.com> <6f0efa9a-876e-4ae1-9367-ccd89f51bab0@xen.org> <33786f0b-eefa-4f1f-ac57-7f1b2c74715e@xen.org> Content-Language: en-US From: Oleksii Kurochko In-Reply-To: <33786f0b-eefa-4f1f-ac57-7f1b2c74715e@xen.org> This is a multi-part message in MIME format. --------------UOzkySSbTXraRu17i4Ezn956 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/1/25 1:59 PM, Julien Grall wrote: > > > On 01/04/2025 07:24, Jan Beulich wrote: >> On 31.03.2025 18:17, Julien Grall wrote: >>> On 31/03/2025 17:14, Jan Beulich wrote: >>>> On 31.03.2025 17:20, Oleksii Kurochko wrote: >>>>> A randconfig job failed with the following issue: >>>>>     riscv64-linux-gnu-ld: Xen too large for early-boot assumptions >>>>> >>>>> The reason is that enabling the UBSAN config increased the size of >>>>> the Xen binary. >>>>> >>>>> Increase XEN_VIRT_SIZE to reserve enough space, allowing both UBSAN >>>>> and GCOV to be enabled together, with some slack for future growth. >>>> >>>> At some point you may want to use 2M mappings for .text (rx), .rodata >>>> (r), and .data (rw). >>> >>> OOI, why would we want to switch to 2MB? At least on Arm, Xen is tiny >>> enough that it can fit in less than a couple of MB. I would expect the >>> same for RISC-V. >> >> For TLB efficiency reasons for example. On x86 we switched to using 2Mb >> pages quite some time back, just to find that (at least) one of the >> bootloaders choked on the then larger binary. Hence we ended up with >> the XEN_ALIGN_2M Kconfig symbol plus the unconditional use of 2Mb >> mappings for xen.efi. For the original change see cf393624eec3 ("x86: >> use 2M superpages for text/data/bss mappings"). > > For Arm, we can using the contiguous bit (it allows to combine a few > entries into one TLB on some CPUs) to reduce the TLB usage. Not sure > if RISC-V has a similar feature. Unfortunately, RISC-V doesn't have such option. ~ Oleksii --------------UOzkySSbTXraRu17i4Ezn956 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 4/1/25 1:59 PM, Julien Grall wrote:


On 01/04/2025 07:24, Jan Beulich wrote:
On 31.03.2025 18:17, Julien Grall wrote:
On 31/03/2025 17:14, Jan Beulich wrote:
On 31.03.2025 17:20, Oleksii Kurochko wrote:
A randconfig job failed with the following issue:
    riscv64-linux-gnu-ld: Xen too large for early-boot assumptions

The reason is that enabling the UBSAN config increased the size of
the Xen binary.

Increase XEN_VIRT_SIZE to reserve enough space, allowing both UBSAN
and GCOV to be enabled together, with some slack for future growth.

At some point you may want to use 2M mappings for .text (rx), .rodata
(r), and .data (rw).

OOI, why would we want to switch to 2MB? At least on Arm, Xen is tiny
enough that it can fit in less than a couple of MB. I would expect the
same for RISC-V.

For TLB efficiency reasons for example. On x86 we switched to using 2Mb
pages quite some time back, just to find that (at least) one of the
bootloaders choked on the then larger binary. Hence we ended up with
the XEN_ALIGN_2M Kconfig symbol plus the unconditional use of 2Mb
mappings for xen.efi. For the original change see cf393624eec3 ("x86:
use 2M superpages for text/data/bss mappings").

For Arm, we can using the contiguous bit (it allows to combine a few entries into one TLB on some CPUs) to reduce the TLB usage. Not sure if RISC-V has a similar feature. 
Unfortunately, RISC-V doesn't have such option.

~ Oleksii
--------------UOzkySSbTXraRu17i4Ezn956--