From: Igor Mammedov <imammedo@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: pbonzini@redhat.com, kevin@koconnor.net, seabios@seabios.org,
qemu-devel@nongnu.org, "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] [RFC] map 64-bit PCI devices after all possible RAM
Date: Thu, 10 Oct 2013 15:12:04 +0200 [thread overview]
Message-ID: <20131010151204.595fa5cd@nial.usersys.redhat.com> (raw)
In-Reply-To: <1381408927.15451.93.camel@nilsson.home.kraxel.org>
On Thu, 10 Oct 2013 14:42:07 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:
> Hi,
>
> > > > 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).
>
> Ok, so there is not really a way around making the location
> configurable. The size isn't needed, qemu can handle this on it's own.
>
> Guess we can just go with Igor's approach then. "etc/mem64-end" is a
> pretty bad name to say "please map 64bit pci bars here" though.
reasoning bind was to tell BIOS where RAM ends and let it decide what
to do with this information.
But we could do other way around and use "etc/pci-info" that was
proposed earlier by Michael, it is already committed into QEMU and
provides start/end of 32/64-bit PCI windows in QEMU view.
We could use pci-info.w64.start as base for 64-bit bars.
If it's good enough, I'll amend my patch to use it.
>
> cheers,
> Gerd
>
>
>
>
next prev parent reply other threads:[~2013-10-10 13:12 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
2013-10-10 12:42 ` Gerd Hoffmann
2013-10-10 13:12 ` Igor Mammedov [this message]
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=20131010151204.595fa5cd@nial.usersys.redhat.com \
--to=imammedo@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=mst@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 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).