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 X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4279CC433F5 for ; Wed, 15 Sep 2021 08:39:33 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D67F8606A5 for ; Wed, 15 Sep 2021 08:39:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D67F8606A5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:42596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQQS4-0007HB-3Q for qemu-devel@archiver.kernel.org; Wed, 15 Sep 2021 04:39:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQQQX-0005wQ-BM for qemu-devel@nongnu.org; Wed, 15 Sep 2021 04:37:57 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:20885) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQQQV-0007Ys-Gt for qemu-devel@nongnu.org; Wed, 15 Sep 2021 04:37:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1631695073; h=from:from:reply-to: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=SByZigJwyPmdwiTi+mf4/Fr1+UHRFaJ9yDMF7YBqFnw=; b=V4zocb7aw/HKRvcci4n8H/IVFejCo5IXEjP9vDFvOfFdEsldCgyly5Gc6GGCAEXvBcmqId VNkEi8RcsnBdrB2rdsrnwxlkGIb0Jp4vtv7qIprS7zBOkj325L+3f7HVLBVovLJlSTR3+q d/dBifsOJ/iXDYj8RfW8GkU1qePARJk= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-455-oWg4v2lYOc2yb6fBYtd2Gg-1; Wed, 15 Sep 2021 04:37:52 -0400 X-MC-Unique: oWg4v2lYOc2yb6fBYtd2Gg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id F3F09835DE0; Wed, 15 Sep 2021 08:37:50 +0000 (UTC) Received: from redhat.com (unknown [10.39.194.233]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A6D7A60C81; Wed, 15 Sep 2021 08:37:46 +0000 (UTC) Date: Wed, 15 Sep 2021 09:37:42 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Thomas Huth Subject: Re: Deprecate 32-bit hosts? (was: Re: [PULL 14/14] hw/arm/aspeed: Add Fuji machine type) Message-ID: References: <20210913161304.3805652-1-clg@kaod.org> <20210913161304.3805652-15-clg@kaod.org> <88c26520-6b87-e7a2-ac78-c1c92477c814@kaod.org> <1949e204-1bce-f15b-553b-1b42b41e3e08@linaro.org> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=216.205.24.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.398, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: Peter Maydell , Samuel Thibault , Andrew Jeffery , Richard Henderson , "qemu-devel@nongnu.org" , "qemu-arm@nongnu.org" , Joel Stanley , Peter Delevoryas , Paolo Bonzini , Philippe =?utf-8?Q?Mathieu-Daud=C3=A9?= , =?utf-8?Q?C=C3=A9dric?= Le Goater Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, Sep 15, 2021 at 09:42:48AM +0200, Thomas Huth wrote: > On 14/09/2021 17.22, Richard Henderson wrote: > > On 9/14/21 5:26 AM, Peter Maydell wrote: > > > (2) RAM blocks should have a length that fits inside a > > >      signed 32-bit type on 32-bit hosts (at least I assume this > > >      is where the 2047MB limit is coming from; in theory this ought > > >      to be improveable but auditing the code for mishandling of > > >      RAMblock sizes to ensure we weren't accidentally stuffing > > >      their size into a signed 'long' somewhere would be kind > > >      of painful) > > > > Recalling that the win64 abi model is p64, i.e. 'long' is still 32-bit > > while pointers are 64-bit, how close do we think we are to this being > > fixed already? > > > > > Even if we did fix (2) we'd need to compromise on (3) > > > sometimes still -- if a board has 4GB of RAM that's > > > not going to fit in 32 bits regardless. But we would be > > > able to let boards with 2GB have 2GB. > > > > I'm not opposed to deprecating 32-bit hosts...  ;-) > > I think we should consider this again, indeed. Plain 32-bit CPUs are quite > seldom these days, aren't they? And I think we urgently need to decrease the > amount of things that we have to test and maintain in our CI and developer > branches... So is there still a really really compelling reason to keep > 32-bit host support alive? I think it probably depends on the architecture to some extent. i386 is possibly getting rare enough to consider dropping, though IIUC, KVM in the kernel still supports it. Would feel odd to drop it in QEMU if the kernel still thinks it is popular enough to keep KVM support. armv7 feels like it is relatively common as 64-bit didn't arrive in widespread use until relatively recent times compared to x86_64. KVM dropped armv7, but then hardware for that was never widespread, so armv7 was always TCG dominated Other 32-bit arches were/are always rare. > Could we maybe also decrease the amount of targets, i.e. merge > qemu-system-x86_64 and qemu-system-i386, merge qemu-system-ppc64 and > qemu-system-ppc, etc. where it makes sense (i.e. where one of the binaries > is a superset of the other)? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|