public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>, edk2-devel@lists.01.org
Cc: leif.lindholm@linaro.org, jordan.l.justen@intel.com,
	Shannon Zhao <zhaoshenglong@huawei.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	qemu devel list <qemu-devel@nongnu.org>,
	gengdongjiu <gengdongjiu@huawei.com>,
	Drew Jones <drjones@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [RFC PATCH] OvmfPkg/AcpiPlatformDxe: lift 4 GB alloc limit for modern ACPI systems
Date: Thu, 1 Jun 2017 22:40:07 +0200	[thread overview]
Message-ID: <e3a61707-2356-7ad3-0efc-e7d0c4115eea@redhat.com> (raw)
In-Reply-To: <ccc0e728-0348-e386-6f71-0c1c69eaa01d@redhat.com>

On 06/01/17 14:25, Laszlo Ersek wrote:

> In QEMU, we could tie both of these extensions to new machine types.
> 
> The result would be:
> 
>   firmware  QEMU  QEMU machine type  result
>   --------  ----  -----------------  -----------------------------------
>   old       new   old                allocate blobs under 4GB
>   old       new   new                breakage, but that's OK, we can
>                                        require refreshed firmware for
>                                        new machine types
>   new       old   old                allocate blobs under 4GB
>   new       new   old                allocate blobs under 4GB
>   new       new   new                allocate blobs from 64-bit space

I think the situation is easier than this. We don't have to tie the
extensions to machine types.

The reason is that old firmware is allowed to fail on new QEMU
(regardless of machine type). Example: the WRITE_POINTER command,
originally introduced for VMGENID. If you run a SeaBIOS binary without
WRITE_POINTER support, in a QEMU VM with "-device vmgenid", the device
will not work. And QEMU doesn't try to prevent that by binding vmgenid
to machine types. Instead, QEMU bundled a SeaBIOS binary with
WRITE_POINTER support, for the release that introduced VMGENID.

(There's no reason for not bundling OVMF and ArmVirtQemu binaries with
QEMU releases now. Gerd already has a build service up and running, at
<http://www.kraxel.org/repos/>.)

The scenario that we *should* avoid is new firmware failing on old QEMU.
And this patch is actually that case, because the new fw would allocate
blobs with such 8-byte addresses that might not fit into 32-bit blob
fields. So, the extensions are necessary, but tying them to machine
types isn't.

  firmware  QEMU  result
  --------  ----  ------------------------------------------------------
  old       new   breakage, but that's OK; we can require refreshed
                    firmware for new QEMU releases
  new       old   allocate blobs under 4GB (alloc zone extension is
                    necessary)
  new       new   allocate blobs from any address range

Thanks
Laszlo


  parent reply	other threads:[~2017-06-01 20:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01 11:22 [RFC PATCH] OvmfPkg/AcpiPlatformDxe: lift 4 GB alloc limit for modern ACPI systems Ard Biesheuvel
2017-06-01 12:25 ` Laszlo Ersek
2017-06-01 15:16   ` Igor Mammedov
2017-06-01 16:37     ` Laszlo Ersek
2017-06-01 20:40   ` Laszlo Ersek [this message]
2017-06-02 14:56     ` Gerd Hoffmann
2017-06-02 22:40       ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3a61707-2356-7ad3-0efc-e7d0c4115eea@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox