From nobody Wed May 15 11:32:54 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of seabios.org designates 78.46.105.101 as permitted sender) client-ip=78.46.105.101; envelope-from=seabios-bounces@seabios.org; helo=coreboot.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of seabios.org designates 78.46.105.101 as permitted sender) smtp.mailfrom=seabios-bounces@seabios.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from coreboot.org (coreboot.org [78.46.105.101]) by mx.zohomail.com with SMTPS id 1708959663230676.5872271699225; Mon, 26 Feb 2024 07:01:03 -0800 (PST) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by coreboot.org (Postfix) with ESMTPA id 002E421BD0; Mon, 26 Feb 2024 15:00:56 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by coreboot.org (Postfix) with ESMTP id 78DA321CA7 for ; Mon, 26 Feb 2024 15:00:41 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-191-JICaDZM1OJe35rPdyKuwfw-1; Mon, 26 Feb 2024 10:00:36 -0500 Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) (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 mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4382E3C14941; Mon, 26 Feb 2024 15:00:36 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0ED0E8CE8; Mon, 26 Feb 2024 15:00:36 +0000 (UTC) Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) id C63981800097; Mon, 26 Feb 2024 16:00:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708959640; 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=AJXmA/uiM2CiZgUxIaaanKCqTGVMkTrrKPly9Q2lwqc=; b=I7Qeob6WtMuLy/xon6S0dWo7+J/mfeV0LNSMxmGezhgbhwcOzrtOxjp9JB++m3iJ5AE4uK yrvqYmppqQ5cdYEdEJ8LnR2+wyVnK4zVhBa331GLngiQoRiKntVY+09q0SAVfRKNmnPiME /TG1lljdMIXZLEK4Bhxbg7yGjiG7t8M= X-MC-Unique: JICaDZM1OJe35rPdyKuwfw-1 Date: Mon, 26 Feb 2024 16:00:34 +0100 From: Gerd Hoffmann To: Max Tottenham Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Message-ID-Hash: BMKKI4DWSQT2ULLDRZBN3EAYXMWGF7HS X-Message-ID-Hash: BMKKI4DWSQT2ULLDRZBN3EAYXMWGF7HS X-MailFrom: kraxel@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-seabios.seabios.org-0; header-match-seabios.seabios.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: seabios@seabios.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [SeaBIOS] Re: Regression 32bit Kernel + Virtio-scsi List-Id: SeaBIOS mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable Authentication-Results: coreboot.org; auth=pass smtp.auth=mailman@coreboot.org smtp.mailfrom=seabios-bounces@seabios.org X-Spamd-Bar: --- X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1708959664980100001 Content-Type: text/plain; charset="utf-8" On Mon, Feb 26, 2024 at 10:56:05AM +0000, Max Tottenham wrote: > On 02/26, Gerd Hoffmann wrote: > > Recommended action: turn off 64-bit support (long mode) in the cpu: > >=20 > > qemu -cpu host,lm=3Doff >=20 > Hi Gerd >=20 > Thanks for the response, >=20 > that gets the VM booting - unfortunately we have many customers who may > be running 32bit distro kernels - we won't know ahead of time before > launching the VM whether they need this compatibility flag or not, I > don't think we can use this as a suitable work-around. You can turn this off completely this way: --- a/src/fw/pciinit.c +++ b/src/fw/pciinit.c @@ -1195,8 +1195,10 @@ pci_setup(void) } } =20 +#if 0 if (CPUPhysBits >=3D 36 && CPULongMode && RamSizeOver4G) pci_pad_mem64 =3D 1; +#endif =20 dprintf(1, "=3D=3D=3D PCI bus & bridge init =3D=3D=3D\n"); if (pci_probe_host() !=3D 0) { Another option would be to try tweak the condition which turns on pci_pad_mem64. The obvious candidate would be to raise the memory limit, i.e. turn this on only in case memory is present above 64G (outside the PAE-addressable physical address space), or choose some value between 4G and 64G. I'm wondering how widespread it is in 2024 to run 32bit kernels with alot of memory? The 32-bit kernel has 1G of kernel address space and can therefore map less than 1G of all RAM permanently. Memory above that limit ('highmem') must be mapped and unmapped if the kernel wants access it. Which is a significant performance hit (compared to a 64bit kernel), and the more memory you add the worse it gets ... Also finding linux distros which provide full i386 support (including timely security updates) becomes increasingly difficult. take care, Gerd _______________________________________________ SeaBIOS mailing list -- seabios@seabios.org To unsubscribe send an email to seabios-leave@seabios.org