qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram
Date: Mon, 16 Dec 2013 13:54:01 +0200

On Mon, Dec 16, 2013 at 10:11:28AM +0100, Gerd Hoffmann wrote:
> Map 3G (i440fx) or 2G (q35) of memory below 4G, so the RAM pieces
> are nicely aligned to gigabyte borders.
> 
> Keep old memory layout for (a) old machine types and (b) in case all
> memory fits below 4G and thus we don't have to split RAM into pieces
> in the first place.  The later makes sure this change doesn't take
> away memory from 32bit guests.
> 
> So, with i440fx and up to 3.5 GB of memory, all of it will be mapped
> below 4G.  With more than 3.5 GB of memory 3 GB will be mapped below
> 4G and the remaining amount will be mapped above 4G.
> 
> Signed-off-by: Gerd Hoffmann <address@hidden>


OK the piix part looks ok to me.  For now I split this
int two patches: for q35 and piix and parked this on my PCI tree.
pushed, so pls check it out.
I also added some comments - see patches I've sent on list.

However, I'm not sure why do we reserve so much memory for q35.

I re-checked the pci express spec, it explicitly says
(Table 7-1: Enhanced Configuration Address Mapping)
that address bits used for ECAM (aka MMCFG) are 20 + n - 1 to 0,
wheren n is bits in the bus number field, so up to 8.
Doing the math we need up to 28 bits that is 256 Megabytes
of memory.

So what's the issue with using up to 3G for RAM?
This makes me think the only issue is that it seems to conflict
with MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT, which we should just get rid of -
it's never actually used.

Does the analysis above make sense to you?

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]