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

[Andrea Arcangeli]

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?

> 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.

> 
> > 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.

> > 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. Did anybody ever
update seabios paravirt protocols before in qemu lifetime? There
wasn't even seabios initially, there shall be a way to upgrade the
bios, isn't there?

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. And mixing it with cmos sounds a bad idea as cmos is
truncated and leads to various variables in current seabios to end up
truncated to 1g instead of 1029g.

If people uses non standard bioses, they better know what they're
doing. And if they want to be really safe and sure it's all tested and
flawless, they should buy RHEL/RHEV in the first place.