Re: [Qemu-devel] [PATCH 1/1] e820: pass high memory too.

[Andrea Arcangeli <aarcange@redhat.com>]

Hi,

On Thu, Oct 17, 2013 at 01:09:38PM +0200, Gerd Hoffmann wrote:
> We have a fw_cfg entry to pass e820 entries from qemu to the firmware.
> Today it's used to pass reservations only.  This patch makes qemu pass
> entries for RAM too.
> 
> This allows to pass RAM sizes larger than 1TB to the firmware and it
> will also allow to pass non-contignous memory ramges should we decide
> to implement that some day, say for our virtual numa nodes.
> 
> Obviously this needs some extra care to not break existing firware.
> 
> SeaBIOS loads the entries and happily adds them without looking at the
> type.  Which is problematic for memory below 4g as this will overwrite
> reservations added for bios memory etc.  For memory above 4g it works
> just fine, seabios will merge the entry derived from cmos with the one
> loaded from fw_cfg.

The reason for not fixing the cmos and defer the fixage of the >1TB
boot, is to develop a better approach, and this mixture of e820 and
cmos doesn't look like an improvement. The only thing it avoids is to
touch seabios but it provides no benefit whatsoever if compared to
fixing the cmos which looks cleaner to me than having to compute a mix
of cmos and e820 in seabios (and potentially having other bioses
following this mix-incomplete-API).

I thought the reason of deferring the fixage of >1TB boot to wait for
a better approach and better API, I didn't think the end result had to
be a mix API that adds no value.

The premise that "this will also allow to pass non-contiguous memory"
is partly false, as you can't use the e820 API below 4g so there's no
way to create non contiguous memory with this mix-cmos-e820-API.


So instead of adding "if (0)" patches and requiring bioses to mix
information from e820 maps and cmos to boot with more than 1TB, why
can't simply seabios can be fixed to preserve its own reservations
(fragmenting the e820 map passed by qemu) while it build the e820 map?

So then we the qemu API becomes:

       e820_add_entry(0, ram_size, E820_RAM);

No mix. And seabios shall as well crash if the highest ram address in
the e820 map provided by qemu (truncated to 40 bits) doesn't match the
cmos information, to be sure we notice if we break backwards
compatibility with the cmos API.

This intermediate mixed paravirt API doesn't make much sense to me.