From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web11.55778.1673532229868325856 for ; Thu, 12 Jan 2023 06:03:50 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bbdn9XW4; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673532229; 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=t+RjgLJX0urvsGy70ETqKEWnXEVvVMxIkaT9uqHby+Y=; b=bbdn9XW4xsXSxovBrJ94n/3L5WSauOkgWM84aMq3VcvFO/mkqvcuju4LvmOP07Vqi84EmW RiaTut/tmGPSVbfPsZUdFy3j8RP8fM6XAm7DMrkNgxxc5Ekigr5Bv8k2YkPJepz39Zk1dm KlGKv2iD1ienuRJhH2a1DMRhY9V3NAU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-466-kXO39ipJM82nczMVGWXqIA-1; Thu, 12 Jan 2023 09:03:46 -0500 X-MC-Unique: kXO39ipJM82nczMVGWXqIA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7BDB0100F907; Thu, 12 Jan 2023 14:03:42 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4B4661415126; Thu, 12 Jan 2023 14:03:42 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id D24011800606; Thu, 12 Jan 2023 15:03:40 +0100 (CET) Date: Thu, 12 Jan 2023 15:03:40 +0100 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: devel@edk2.groups.io, Pawel Polawski , Jiewen Yao , Oliver Steffen , Jordan Justen , Ard Biesheuvel Subject: Re: [PATCH v2 2/4] OvmfPkg/PlatformInitLib: Add PlatformGetLowMemoryCB Message-ID: <20230112140340.wayqeuwh2d3gcp3s@sirius.home.kraxel.org> References: <20230110082123.159521-1-kraxel@redhat.com> <20230110082123.159521-3-kraxel@redhat.com> <043b03d6-0a6b-c533-255b-24a7805d5cca@redhat.com> <20230111072925.l47t4ahgynqjyegq@sirius.home.kraxel.org> <4ace3789-7192-0c53-b4b2-f62f907176d0@redhat.com> <20230111152341.d3p6iy5pml7shfvk@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > I think it should actually simplify things. All the inconsistencies we > > have (as you outlined above) due to the hole punching and edk2 > > supporting only a single range for 32bit mmio should go away, and we > > will have less address space layout differences between q35 and pc. > > We've tried 0xE000_0000 in the past, in commit 75136b29541b. > > But had to revert it in commit eb4d62b0779c, due to 0xE000_0000 tickling > a bug in QEMU. > > The bug tickling was actually reported by you :) See > . Oh. I totally forgot about that. The patch from (I think) 2019 which added _CRS for the range below the MMCONFIG should have fixed that, and with recent qemu everything works fine. I suspect we can't easily detect whenever qemu is broken or not. Hmm. Is more than three years being passed enough to just do it unconditionally and effectively raise the bar for the minimum supported qemu version? > (Well, if you mean to keep the same logic for both i440fx adn q35, > that's OK then.) Yes, it would be Uc32Base. LowMemory and Uc32Base are identical anyway most of the time due to qemu preferring gigabyte pages when possible, you need odd memory sizes like 1.5 or 2.5 GB to see they actually can be different. take care, Gerd