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

[Gerd Hoffmann]

On Fr, 2013-10-18 at 15:31 +0200, Andrea Arcangeli wrote:
> On Fri, Oct 18, 2013 at 10:55:12AM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > > > > 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.
> > > > 
> > > > Sure you can.  Why do you think you can't?
> > > 
> > > How do you specify an hole below 4g unless you modify seabios first?
> > 
> > First chunk of memory in cmos.
> > Full list in e820 (first chunk temporarily disabled).
> 
> How do you know the full list below 4g isn't wiping out non-ram
> seabios mappings?

Unlikely, but might happen if you have pci devices with large bars.

seabios needs updates to handle non-contignous memory correctly.  First,
for this one.  Second, to fix the same issue above 4G (as you've raised
in your previous mail).  Third, to make sure smbios information is
correct.  Maybe more.

But that is (a) internal to seabios and doesn't require adjustments to
the qemu/seabios interface and (b) only needed to handle stuff not
working today, i.e. there are no regressions.

> > To get more than 1TB work correctly (with all corner cases covered) both
> > qemu and seabios need to be updated.  No matter whenever we'll go
> > implement that using cmos, by extending e820 interface or using a new
> > e820 interface.
> 
> Agreed.
> 
> > 
> > >  So "high" is 1g in seabios. So
> > > RamSizeOver4G is 1g.
> > 
> > Patch to address that exists.
> 
> I don't get what you mean here.

Patch for seabios, not qemu.  RamSizeOver4G must be adjusted according
to the e820 entries.

> > > In short your change is already breaking current seabios.
> > 
> > No.
> 
> I guess next thing is to try if it kernel boots and the root
> filesystem gets mounted with -m 1029g. Maybe something lucky happens
> and it actually boots but I think there's a reasonable chance that it
> doesn't boot considering the broken addresses where it will map pci
> space and other bits.

Likewise broken without the patch, possibly with other symptoms.
More than 1TB just doesn't work correctly without patching both qemu and
seabios.

> > > When seabios speaks the new paravirt interface, only then modify qemu
> > > to use the new paravirt interface.
> > 
> > This isn't RHEL.  We can't enforce any ordering with rpm dependencies.
> 
> We ship the bios.bin binary in qemu? In the same commit you add a
> proper paravirt interface and you update bios.bin.

That doesn't help much.  Distros usually compile seabios themself from
the sources.

> Did anybody ever
> update seabios paravirt protocols before in qemu lifetime?

The process is:

  (1) commit patches to qemu.
  (2) commit patches to seabios.
  (3) wait for next seabios release.
  (4) update seabios.

> Furthermore by adding a new fw_cfg like I suggested above (which is
> the only way to avoid breaking current seabios interface), old seabios
> and new seabios can keep working fine. The current e820 API simply is
> unusable if seabios overwrites the non-ram ranges it reserved
> earlier.

I'll go brew up patches doing that.

cheers,
  Gerd