Re: [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Jan 20, 2014 at 03:01:50PM +0100, Gerd Hoffmann wrote:
> On Mo, 2014-01-20 at 15:59 +0200, Michael S. Tsirkin wrote:
> > On Mon, Jan 20, 2014 at 01:58:45PM +0100, Gerd Hoffmann wrote:
> > > On Mo, 2014-01-20 at 13:23 +0200, Michael S. Tsirkin wrote:
> > > > On Tue, Dec 17, 2013 at 06:56:06PM +0100, Gerd Hoffmann wrote:
> > > > > > I merged your patch but split it: q35 is separate and piix
> > > > > > is separate. Would you like me to drop the q35 part then?
> > > > > 
> > > > > If you are fine with q35 having only 2G lowmem keep it.  It's safe.
> > > > > 
> > > > > We can sort the mmconfig setup afterwards, then check if (and how) we'll
> > > > > transition to 3G lowmem.  Maybe we simply don't after all, with the
> > > > > world moving to 64bit it doesn't matter that much whenever memory is
> > > > > mapped above or below 4g.  And for old 32bit guests there is always the
> > > > > option to stick with piix which continues to offers up to 3.5G lowmem.
> > > > > 
> > > > > cheers,
> > > > >   Gerd
> > > > > 
> > > > 
> > > > Any update here?
> > > 
> > > No time to investigate yet, still playing catch-up after xmas holidays &
> > > being sick.
> > > 
> > > > I'm worried 2G lowmem is a bit too aggressive, PAE still exists.
> > > 
> > > piix (with up to 3.5g lowmem) exists too ;)
> > 
> > Yes but I think it's preferable to keep features orthogonal.
> > 
> > > > If we want to support old bios, one way would be to add
> > > > a new register to enable 3g lowmem.
> > > 
> > > Do we really want do this (allow guest change RAM mapping)?
> > > 
> > > I think we should:
> > >  (1) reserve mmconf xbar as motherboard ressource, so it can live within
> > >      PCI0._CRS
> > 
> > I don't think this is possible, PCI FW spec seems to
> > outlaw this explicitly.
> 
> Nevertheless my laptop does it this way, and it would simplify things
> because we'll need a single mmio range below 4k then.
> 
> Have a pointer to the spec?

I refer to this:

4.1.2.
 MCFG Table Description


...

If the operating system does not natively comprehend reserving the MMCFG
region, the MMCFG region must be reserved by firmware. The address range
reported in the MCFG table or by _CBA method (see Section 4.1.3) must be
reserved by declaring a motherboard resource.  For most systems, the
motherboard resource would appear at the root of the ACPI namespace
(under \_SB) in a node with a _HID of EISAID (PNP0C02), and the
resources in this case should not be claimed in the root PCI bus’s _CRS.
The resources can optionally be returned in Int15 E820 or
EFIGetMemoryMap as reserved memory but must always be reported through
ACPI as a motherboard resource.


So if we care about legacy OS-es we must make MCFG a motherboard
resource and it must not be part of _CRS.


> > Right. So you'll look into 4 then? I'm keeping these
> > patches out of tree for now ...
> 
> Still plan to care when I find time, yes.
> 
> cheers,
>   Gerd
>