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 2005FC54E41 for ; Thu, 29 Feb 2024 12:32:31 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.687012.1069696 (Exim 4.92) (envelope-from ) id 1rffaI-0006M2-WD; Thu, 29 Feb 2024 12:32:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 687012.1069696; Thu, 29 Feb 2024 12:32:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rffaI-0006Lv-TK; Thu, 29 Feb 2024 12:32:22 +0000 Received: by outflank-mailman (input) for mailman id 687012; Thu, 29 Feb 2024 12:32:21 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rffaH-0006Lp-00 for xen-devel@lists.xenproject.org; Thu, 29 Feb 2024 12:32:21 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rffaF-0003jf-Nb; Thu, 29 Feb 2024 12:32:19 +0000 Received: from [15.248.3.86] (helo=[10.45.19.50]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1rffaF-0001An-GY; Thu, 29 Feb 2024 12:32:19 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=yi26Zld1whDZBg0WiyiEQrqeOGpI97uU3msBEwI+Unc=; b=ZsncASid21OMOX2sfq/p0sr+/Q YQR3Noe4KtcbmfKr3OOhi87CXzfzmM0grFlY8E7cAikTBha8ycFglAQn4Mzrn30/fLqHzyN4pJktv QzMCO6kkpMTJNyOsGn50PjaYouvGhLgyMC8YyOom3y/2F81Q7Isd38cZ4omi3uhfH9Ps=; Message-ID: <9b212dec-59ef-4cbb-bea7-add3867e4599@xen.org> Date: Thu, 29 Feb 2024 12:32:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 23/23] xen/README: add compiler and binutils versions for RISC-V64 Content-Language: en-GB To: Jan Beulich , Andrew Cooper Cc: George Dunlap , Stefano Stabellini , Wei Liu , xen-devel@lists.xenproject.org, Oleksii Kurochko References: <73a38d85-0798-4cfa-8625-0f8c9e05b2a3@suse.com> <80fb8091-9a26-40a4-b2e7-371df9411861@xen.org> <889b132b-b92e-465b-94af-4e4133e4c297@suse.com> <52188e88-374c-449f-a71c-bfce9b6d07f4@xen.org> <2a112321-f4fd-4ab4-a431-a0bb4cb6eaa2@suse.com> From: Julien Grall In-Reply-To: <2a112321-f4fd-4ab4-a431-a0bb4cb6eaa2@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 29/02/2024 12:17, Jan Beulich wrote: > On 29.02.2024 13:05, Andrew Cooper wrote: >> On 29/02/2024 10:23 am, Julien Grall wrote: >>>>>> IOW it is hard for me to see why RISC-V needs stronger restrictions >>>>>> here >>>>>> than other architectures. It ought to be possible to determine a >>>>>> baseline >>>>>> version. Even if taking the desire to have "pause" available as a >>>>>> requirement, gas (and presumably gld) 2.36.1 would already suffice. >>>>> >>>>> I think we want to bump it on Arm. There are zero reasons to try to >>>>> keep >>>>> a lower versions if nobody tests/use it in production. >>>>> >>>>> I would suggest to do the same on x86. What's the point of try to >>>>> support Xen with a 15+ years old compiler? >>>> >>>> It could have long been bumped if only a proper scheme to follow for >>>> this and future bumping would have been put forward by anyone keen on >>>> such bumping, like - see his reply - e.g. Andrew. You may recall that >>>> this was discussed more than once on meetings, with no real outcome. >>>> I'm personally not meaning to stand in the way of such bumping as long >>>> as it's done in a predictable manner, but I'm not keen on doing so and >>>> hence I don't view it as my obligation to try to invent a reasonable >>>> scheme. (My personal view is that basic functionality should be >>>> possible to have virtually everywhere, whereas for advanced stuff it >>>> is fine to require a more modern tool chain.) >>> >>> That's one way to see it. The problem with this statement is a user >>> today is mislead to think you can build Xen with any GCC versions >>> since 4.1. I don't believe we can guarantee that and we are exposing >>> our users to unnecessary risk. >>> >>> In addition to that, I agree with Andrew. This is preventing us to >>> improve our code base and we have to carry hacks for older compilers. >> >> I don't think anyone here is suggesting that we switch to a >> bleeding-edge-only policy.  But 15y of support is extreme in the >> opposite direction. >> >> Xen ought to be buildable in the contemporary distros of the day, and I >> don't think anyone is going to credibly argue otherwise. >> >> But, it's also fine for new things to have newer requirements. >> >> Take CET for example.  I know we have disagreements on exactly how it's >> toolchain-conditionalness is implemented, but the basic principle of "If >> you want shiny new optional feature $X, you need newer toolchain $Y" is >> entirely fine. >> >> A brand new architecture is exactly the same.  Saying "this is the >> minimum, because it's what we test" doesn't preclude someone coming >> along and saying "can we use $N-1 ?  See here it works, and here's a >> change to CI test it". >> >> >> Anyway, its clear we need to write some policy on this, before making >> specific adjustments.  To get started, is there going to be any >> objection whatsoever on some principles which begin as follows: > > Largely not, but one aspect needs clarifying up front: > >> * For established architectures, we expect Xen to be buildable on the >> common contemporary distros.  (i.e. minima is not newer than what's >> available in contemporary distros, without a good reason) > > What counts as contemporary distro? Still in normal support? LTS? Yet > more extreme forms? LTS makes sense. More I am not sure. I am under the impression that people using older distros are those that wants a stable system. So they would unlikely try to upgrade the hypervisor. Even for LTS, I would argue that if it has been released 5 years ago, then you probably want to update it at the same time as moving to a newer Xen version. Cheers, -- Julien Grall