From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>,
kevin@koconnor.net, seabios@seabios.org, qemu-devel@nongnu.org,
pbonzini@redhat.com
Subject: Re: [Qemu-devel] [RFC] map 64-bit PCI devices after all possible RAM
Date: Thu, 10 Oct 2013 15:21:32 +0300 [thread overview]
Message-ID: <20131010122132.GA7884@redhat.com> (raw)
In-Reply-To: <1381407256.15451.86.camel@nilsson.home.kraxel.org>
On Thu, Oct 10, 2013 at 02:14:16PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > I think the simplest way to do all this is simply to tell seabios
> > that we have more memory. seabios already programs 64 bit BARs
> > higher than memory.
>
> Hmm? As I understand Igor just wants some address space for memory
> hotplug. So there wouldn't be memory there (yet). And telling seabios
> there is although there isn't will make seabios place wrong info into
> the e820 tables. Not going to fly.
True. Maybe we should get some smbios stuff from qemu too.
> > I think the issue is with legacy guests.
> > E.g. if VCPU claims to support 50 bit of memory
> > do we put high PCI memory at 1 << 50?
> > If yes old guests which expect at most 40 bit
> > will not be able to use it.
>
> Hmm. Sure such guests exist?
I wouldn't be surprised. At least some windows
guests crash if you try to tell them your system
has too much physical memory (e.g. 2^48).
> Note this is physical address lines, not
> virtual address space (where you might need an additional level of
> pagetables to fully use it, which is not something we could expect old
> guests being able to handle).
>
> cheers,
> Gerd
>
next prev parent reply other threads:[~2013-10-10 12:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 12:23 [Qemu-devel] [RFC] map 64-bit PCI devices after all possible RAM Igor Mammedov
2013-10-09 13:12 ` Gerd Hoffmann
2013-10-09 17:27 ` Igor Mammedov
2013-10-10 10:56 ` Gerd Hoffmann
2013-10-10 11:35 ` Michael S. Tsirkin
2013-10-10 12:14 ` Gerd Hoffmann
2013-10-10 12:21 ` Michael S. Tsirkin [this message]
2013-10-10 12:42 ` Gerd Hoffmann
2013-10-10 13:12 ` Igor Mammedov
2013-10-10 13:21 ` Gerd Hoffmann
2013-10-10 13:50 ` Igor Mammedov
2013-10-11 6:28 ` Gerd Hoffmann
2013-10-10 13:17 ` Igor Mammedov
2013-10-10 11:40 ` Michael S. Tsirkin
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=20131010122132.GA7884@redhat.com \
--to=mst@redhat.com \
--cc=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.