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.129.124]) by mx.groups.io with SMTP id smtpd.web10.16416.1684829113718966439 for ; Tue, 23 May 2023 01:05:14 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LMLNJdBv; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684829112; 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+YPSGoORA3zUJORQ+lXI9+pbXQ+RD5gHmfA54UDu8=; b=LMLNJdBvbvglABk2EXCR0kW4psOyE1ks127+xRdNEUju9en5JPhe1XFsPbJ7tKE8ChUe9l eh5d5Z6F+/y2ck1LMnptg8XWubPBe9PkY2cbIxZHKLj3jGuYLeMSzRHT0U8x56CJXX6zK2 mEBPdahr3q0W9S9KS8N57+MOCQOM3fc= 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-279-mVf7fZoRNyWDNpnD3U9uUw-1; Tue, 23 May 2023 04:05:08 -0400 X-MC-Unique: mVf7fZoRNyWDNpnD3U9uUw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DFAF1811E8D; Tue, 23 May 2023 08:05:07 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.37]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2CF41121314; Tue, 23 May 2023 08:05:07 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 670EA180614D; Tue, 23 May 2023 10:05:06 +0200 (CEST) Date: Tue, 23 May 2023 10:05:06 +0200 From: "Gerd Hoffmann" To: Laszlo Ersek Cc: "Ni, Ray" , Ard Biesheuvel , edk2-devel-groups-io , "Yao, Jiewen" , Taylor Beebe , Oliver Smith-Denny Subject: Re: managing memory attributes in PEI Message-ID: References: <1718e8ad-6ba3-5da8-85c5-76e48c42110d@redhat.com> <2e04e9da-5b5a-9c00-76fe-c149538ddc80@redhat.com> MIME-Version: 1.0 In-Reply-To: <2e04e9da-5b5a-9c00-76fe-c149538ddc80@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > >> Before we enabled SMM for OVMF, we had never really used IA32X64 OVMF -- > >> SMM-less ACPI S3 resume had just worked fine with X64-only OVMF. IA32X64 > >> only proved a great platform option to fall back to, when we realized > >> that on X64 OVMF, ACPI S3 resume wouldn't just seamlessly extend to SMM. > > > > I don't quite understand. So, what's the conclusion of IA32X64 OVMF? Keep it? Remove it? > > As long as edk2 (core modules) will continue supporting IA32X64 firmware > platforms, I think keeping OVMF IA32X64 is useful, minimally as a test > bed for those core modules / PCDs / boot paths. Agree. I'll go switch downstream SMM-enabled builds from OvmfPkgIa32X64.dsc to OvmfPkgX64.dsc ASAP, so for virtualization use cases OvmfPkgIa32X64.dsc will not be needed any more. But it indeed makes sense to keep OvmfPkgIa32X64.dsc for testing and CI purposes. So the question what the future of OvmfPkgIa32X64.dsc (and OvmfPkgIa32.dsc) should be is is more a question of what the overall edk2 plans for IA32 are. take care, Gerd