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.web08.14884.1629897219239935154 for ; Wed, 25 Aug 2021 06:13:39 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=T6otFfo6; 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=1629897218; 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=G0747iyVboeuaWnK6Gezl3NIZOJSVmT6C3i0XzRUq+Y=; b=T6otFfo6K3lY9A3aazUhXWfiuYZaATl7EypEUfF6Aq8tEwDz1i17FXEgSVei15md/MpNlA 3rjeEQOmj4Un6G/aWk5kp294rPGB82yMubDQ/GkTCMBs5Uz454Kg5XxjVXDZAmIJcpFSdJ wjWv6BLeu9q6eMamB5B+Vvatp447tss= 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-264-IsYF6VE4MyOnLj59OM2Exg-1; Wed, 25 Aug 2021 09:13:34 -0400 X-MC-Unique: IsYF6VE4MyOnLj59OM2Exg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CAA78801AC5; Wed, 25 Aug 2021 13:13:33 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8E5115C25A; Wed, 25 Aug 2021 13:13:33 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id D13501800903; Wed, 25 Aug 2021 15:13:31 +0200 (CEST) Date: Wed, 25 Aug 2021 15:13:31 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" Subject: Re: [edk2-devel] [PATCH 2/2] OvmfPkg/PlatformPei: prefer etc/e820 for memory detection Message-ID: <20210825131331.5mh76tk5vntapwbj@sirius.home.kraxel.org> References: <20210819081110.1612205-1-kraxel@redhat.com> <20210819081110.1612205-3-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Aug 25, 2021 at 09:24:43AM +0000, Yao, Jiewen wrote: > Hi > Would you please follow EDKII process? > 1) File an EDKII Bugzilla. Ok, will do. > 2) CC all reviewers in OVMF package. Is there some way to automate this? I see there is BaseTools/Scripts/GetMaintainer.py, but the script wants a commit hash not a patch file as argument, so I can't hook it into 'git send-email'. > Please also describe what the reason of change, what is the benefit we > can get from the change? > > I just feel it is confusing. Previously, the data is consistent from > CMOS. Now, we have two ways to get one data from different sources. It is *not* consistent from CMOS. CMOS is only used for memory below 4G whereas the etc/e820 fw_cfg file is used for memory above 4G. So this patch actually makes things more consistent. > Please help me understand: > > A) What if the data are different from different source? > > B) Why we choose to trust E820 at first, the CMOS? Not verse versa. e820 is the newer and more capable interface, specifically cmos can handle at most 1TB of memory (which is the reason why e820 is already used to detect high memory). > C) If we trust E820 (in B), then why we need go back to CMOS, if LowMemorySize is 0? Backward compatibility with old qemu versions. etc/e820 is available in qemu version 1.7 (released Nov 2013) and newer. Does OVMF have any policy for backward compatibility? If breaking compatibility with qemu versions that old is acceptable I happily delete any CMOS access from qemu PlatformPei and throw an assert() instead. take care, Gerd