From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4003:c0f::233; helo=mail-ot0-x233.google.com; envelope-from=saxenap.ltc@gmail.com; receiver=edk2-devel@lists.01.org Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 598BF211435A0 for ; Wed, 6 Jun 2018 03:57:45 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id m11-v6so6611677otf.3 for ; Wed, 06 Jun 2018 03:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bo97zsEQ2z7k1jorK3h3Qp+3n2d0/kEkarBAhBeSUms=; b=uYjM48k2yX6BQt8PU335zRGYnQjFZ1Ijazr5mKEUkdHHeSd8Nlt5WruOKKSDZIZZou EwdjzzrfLqPWgm4I0M10qCAqCEDZ89voUFHz7bvFLEzVTICqL2UfeOLujMOn5dwR5afL hQAlusKjbUL8PM13SCX3NEGC64oidSgW5oYIpG4Dy3gj7Vqi1UKaO8dci7mBsc2VPTtC auwrNQXKzwHCI7ZZzOqDkA4TI83qnnks+rZSrWqGk/bSS21wY6nWoEayNa4LDMZPp2+i CItl29ys+IrrF5A0U3lX9o2KvPPVIPIX6NBmU3zSIABSjcCbLjIJgfKvLK0ahr8fHff9 i79A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bo97zsEQ2z7k1jorK3h3Qp+3n2d0/kEkarBAhBeSUms=; b=G7ac+mfX91FK+eiH4N6VNcRKSgMwYmt2Kpgskz4HEHkyyTv6xeMtYOR0CvoemkVxjo aDHR5Eux0lrjUeZMXc+JI2f3fGyTRRpc4JC/NDYs0fWhApdd4MFY+zQKXiun64s9uF6r TOBlnWh/Hqo5z8CBlYuO6TkuxldWJQNCDwGOlEOvxaYGBV+xT3kHqmyE8tzVO63Wblr5 esX/4w52b0fSW+C+55n4h7QfdrbeCf2hyatA6sGBRUN/bfPS0KI4Hqk8XMUYbbxnqNgd LMhYERfKTZdU58gfaVnoe28R4T3xBAMDqjq5a+39b2FHmwvWoFfURHQcNMd5WiWpksCU EUFA== X-Gm-Message-State: APt69E0zkR9y0HFvi1pw59SZagH5np8vgR9k5VqBl15gNzOMQUhCriHF Vo4h8A28raKlb5Tqy7/mJy87rAgRb0qlhPgVcyU= X-Google-Smtp-Source: ADUXVKKbINfy+LouNdkp3tTC/DYn0rV9yXsP1EzlLUCXRnI9mPILq9Kc0bNZfqGb25UauOJr/al54ozxko7rbngwO4c= X-Received: by 2002:a9d:2b32:: with SMTP id o47-v6mr1694329otb.346.1528282663905; Wed, 06 Jun 2018 03:57:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1a22:0:0:0:0:0 with HTTP; Wed, 6 Jun 2018 03:57:43 -0700 (PDT) In-Reply-To: <972162c0-33f8-8234-0304-855089c094ca@redhat.com> References: <972162c0-33f8-8234-0304-855089c094ca@redhat.com> From: Prerna Date: Wed, 6 Jun 2018 16:27:43 +0530 Message-ID: To: Laszlo Ersek Cc: edk2-devel@lists.01.org X-Mailman-Approved-At: Wed, 06 Jun 2018 06:33:36 -0700 X-Content-Filtered-By: Mailman/MimeDel 2.1.26 Subject: Re: 4MB flash size as build default. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2018 10:57:45 -0000 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 6, 2018 at 4:02 PM, Laszlo Ersek wrote: > On 06/06/18 05:05, Prerna wrote: > > Hi Laszlo, > > I noticed that the following commit was used to make the 4MB flash layout > > the default for edk2 builds briefly: > > > > bba8dfbec3bb OvmfPkg: make the 4MB flash size the default > > > > However, it was later reverted : > > > > 6e49d01cfb43 Revert "OvmfPkg: make the 4MB flash size the default" > > > > presumably to fix this issue: > > > > 0c79471d6a98 OvmfPkg/PlatformPei: handle non-power-of-two spare > > size for emu variables > > No, that's not exactly the reason. Please see the following sub-thread: > > http://mid.mail-archive.com/bdf196e8-df87-84b9-1d6e- > bbece5fa65b7@redhat.com > > Briefly, the 4MB unified pflash size broke two things: > - the EmuVariableFvbRuntimeDxe driver, which would only affect QEMU > command lines with -bios, > - the PlatformPei PEIM, which would affect QEMU command lines with > -pflash too. > > (In the linked message, I explained why I hadn't noticed even regression > #2.) > > The temporary solution was to (a) restore the default to 2MB -- this > would allow people to continue using both -bios and -pflash, and (b) > kludge around the PlatformPei regression, so that the (manually > selected) 4MB build would be usable for -pflash, at the cost of wasting > a little bit of reserved memory. > > In other words, the last two commits that you list have no > inter-dependency between them, instead they mitigated two aspects of the > regression. > > In the longer term, I extended EmuVariableFvbRuntimeDxe (and the > interfacing code in PlatformPei) to handle the new 4MB unified size as > well. Please refer to > . This completed the > 4MB support for "-bios" from the OVMF side; however it turned out that > even Xen needed fixes. > > Once Xen too received the necessary patches, we re-enabled the 4MB > default size (commit 1c47fcd465a4 -- basically a re-application of > commit bba8dfbe). Please refer to > db629722c70a@redhat.com>, > and the other message it references. > > > Given that the above commit was also merged, why does edk2 still default > to > > the 2MB flash layout for builds? > > It doesn't; if you build upstream edk2, it defaults to 4MB. > Thank you. It appears I had missed the new commits that re-enabled the 4MB size as default. > > We preserved the 2MB unified size in Gerd's and Fedora's OVMF builds > because the varstore structures are incompatible between the 2MB and the > 4MB builds. (Please refer to section "OVMF Flash Layout" in the > "OvmfPkg/README" file.) If you have a preexistent varstore file, > originally created from the OVMF_VARS.fd template of the 2MB build, and > then you boot the same VM with the OVMF_CODE.fd binary of the 4MB build, > your VM will not boot. (It will just hang with a black screen. If you > capture the OVMF debug log, you will get some error messages, but > practically no user ever captures the debug log.) > > In other words, we preserved the 2MB unified size in Fedora and in > Gerd's repo for staying compatible with the existent VMs of the users of > those distros / repos. > yes, I had played around with these two different layouts. I found my VMs to hang and not boot in case I mismatched the OVMF_VARS.fd. > > As one counter-example, we switched from 2MB to 4MB in RHEL-7.4. This > broke compatibility with VMs created against OVMF in RHEL-7.3, but that > was fine: in RHEL-7.3, OVMF was Tech Preview, and breaking compat with > Tech Preview packages is explicitly permitted. > > Now obviously users of Fedora and Gerd's repo aren't *officially* > entitled to any kind of stability or support (which is why I don't run > Fedora for my day to day work, by the way), so we could have broken > compat there as well, right? Well, yes, if only we had wanted to field > tens or maybe hundreds of complaints on the vfio-users mailing list and > elsewhere. :) Those users most likely didn't *need* the 4MB build -- see > the motivation for the 4MB build in commit b24fca05751f --, hence > keeping compat for them was more important. Regarding direct consumers > of the upstream edk2 *source* tree, we figured they were technical > enough to deal with the change in the default size. > > > Do you see any other issues too with the 4MB flash layout ? > > Nope. > > If you really want to use the 4MB build in Fedora (although I don't see > why you would), it's technically possible to provide the split 4MB build > in addition to the current files (under different filenames). In that > case, please file an RHBZ for the "edk2" component in Fedora (and CC > Gerd on it so he can adapt his package as well, if he intends to). > > I do not necessarily need Fedora. Will be happy to build from upstream. Thank you for patiently explaining the implications of non-power-of-2 for EmuVariableFvbRuntimeDxe. My limited reading had just spotted the breakage for PlatformPei PEIM. This clearly was a commit I had missed from looking at upstream git log. Regards, Prerna