qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <aliguori@amazon.com>
Subject: Re: [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram
Date: Mon, 16 Dec 2013 13:54:01 +0200	[thread overview]
Message-ID: <20131216115401.GA19233@redhat.com> (raw)
In-Reply-To: <1387185088-16811-1-git-send-email-kraxel@redhat.com>

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 <kraxel@redhat.com>


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	other threads:[~2013-12-16 11:50 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-16  9:11 [Qemu-devel] [PATCH v2] x86: gigabyte alignment for ram Gerd Hoffmann
2013-12-16 11:54 ` Michael S. Tsirkin [this message]
2013-12-16 13:46   ` Gerd Hoffmann
2013-12-16 19:28     ` Michael S. Tsirkin
2013-12-17 10:54       ` Gerd Hoffmann
2013-12-17 11:59         ` Michael S. Tsirkin
2013-12-17 17:56           ` Gerd Hoffmann
2013-12-18 10:05             ` Michael S. Tsirkin
2014-01-20 11:23             ` Michael S. Tsirkin
2014-01-20 12:58               ` Gerd Hoffmann
2014-01-20 13:59                 ` Michael S. Tsirkin
2014-01-20 14:01                   ` Gerd Hoffmann
2014-01-20 14:22                     ` Michael S. Tsirkin
2014-01-20 15:36                       ` Gerd Hoffmann
2014-01-20 15:51                         ` Michael S. Tsirkin
2014-01-20 17:15                           ` Igor Mammedov
2014-01-21  7:27                             ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131216115401.GA19233@redhat.com \
    --to=mst@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).