From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Marcel Apfelbaum <marcel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
qemu-devel@nongnu.org, Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: Allow physical address bits to be set)
Date: Thu, 30 Jun 2016 18:12:34 +0100 [thread overview]
Message-ID: <20160630171233.GE2683@work-vm> (raw)
In-Reply-To: <1467303289.15123.102.camel@redhat.com>
* Gerd Hoffmann (kraxel@redhat.com) wrote:
> > So that's mapped at an address beyond host phys-bits.
> > And it hasn't failed/crashed etc - but I guess maybe nothing is using that 2G space?
>
> root@fedora ~# dmesg | grep Surface
> [ 4.830095] [drm] qxl: 2048M of Surface memory size
>
> qxl bar 4 (64bit) and qxl bar 1 (32bit) are the same thing. The 64bit
> bar can be alot larger obviously. The 32bit bar is just an alias for
> the first portion of the 64bit bar. So I guess qxl just falls back to
> use bar 1 instead of bar 4 because ioremap() on bar 4 fails.
Hmm for me it's saying it mapped 64M on the setup with 64T maxmem and 48bit phys-bits;
even though the bar is showing it as OK; how is the guest ioremap detecting a problem?
> > Obviously 128T is a bit silly for maxmem at the moment, however I was worrying what
> > happens with 36/39/40bit hosts, and it's not unusual to pick a maxmem that's a few TB
> > even if the VMs you're initially creating are only a handful of GB. (oVirt/RHEV seems to use
> > a 4TB default for maxmem).
>
> Oh, ok. Should be fixed I guess.
>
> > Still, this only hits as a problem if you hit the combination of:
> > a) You use large PCI bars
>
> ovmf will map all 64bit bars high, even without running out of 32bit
> address space. And with virtio 1.0 pretty much every virtual machine
> will have 64bit bars.
Hmm OK let me think about this; using current BIOS+old virtio+host phys-bits
on a 36bit host, with maxmem=4T would apparently work because
nothing would actually get mapped that high.
The same with OVMF would work as well, because generally you wouldn't have
any 64bit bars; but then you turn on virtio 1.0 and.. well then what happens?
The guest sees it's 36bit phys-address bits so linux probably drops the
bars associated with the virtio? Hmm.
With current downstream qemu's 40bit physical address bit you'd
get those bar's mapped; so it might break badly - except if
we can figure out what causes my 2GB qxl bar not to happen
as at the start of this message.
Dave
> cheers,
> Gerd
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2016-06-30 17:12 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-16 17:12 [Qemu-devel] [PATCH 0/5] x86: Physical address limit patches Dr. David Alan Gilbert (git)
2016-06-16 17:12 ` [Qemu-devel] [PATCH 1/5] BIT_RANGE convenience macro Dr. David Alan Gilbert (git)
2016-06-16 17:23 ` Paolo Bonzini
2016-06-16 17:24 ` Dr. David Alan Gilbert
2016-06-16 18:01 ` Peter Maydell
2016-06-16 18:05 ` Paolo Bonzini
2016-06-20 14:11 ` Dr. David Alan Gilbert
2016-06-20 14:17 ` Peter Maydell
2016-06-16 17:12 ` [Qemu-devel] [PATCH 2/5] x86: Mask mtrr mask based on CPU physical address limits Dr. David Alan Gilbert (git)
2016-06-16 19:59 ` Eduardo Habkost
2016-06-17 8:23 ` Dr. David Alan Gilbert
2016-06-17 12:13 ` Paolo Bonzini
2016-06-16 17:12 ` [Qemu-devel] [PATCH 3/5] x86: fill high bits of mtrr mask Dr. David Alan Gilbert (git)
2016-06-16 20:14 ` Eduardo Habkost
2016-06-17 7:47 ` Paolo Bonzini
2016-06-17 12:46 ` Eduardo Habkost
2016-06-17 13:01 ` Paolo Bonzini
2016-06-17 13:41 ` Eduardo Habkost
2016-06-17 14:25 ` Paolo Bonzini
2016-06-17 15:27 ` Eduardo Habkost
2016-06-17 15:29 ` Paolo Bonzini
2016-06-17 15:35 ` Eduardo Habkost
2016-06-17 13:51 ` Dr. David Alan Gilbert
2016-06-17 14:19 ` Paolo Bonzini
2016-06-17 8:53 ` Dr. David Alan Gilbert
2016-06-16 17:12 ` [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set Dr. David Alan Gilbert (git)
2016-06-16 17:26 ` Paolo Bonzini
2016-06-16 18:09 ` Eduardo Habkost
2016-06-16 20:24 ` Eduardo Habkost
2016-06-17 8:15 ` Dr. David Alan Gilbert
2016-06-17 8:43 ` Paolo Bonzini
2016-06-17 9:17 ` Gerd Hoffmann
2016-06-17 9:52 ` Igor Mammedov
2016-06-17 11:20 ` Gerd Hoffmann
2016-06-17 16:20 ` Laszlo Ersek
2016-06-17 16:07 ` Laszlo Ersek
2016-06-19 16:13 ` Marcel Apfelbaum
2016-06-20 10:42 ` Igor Mammedov
2016-06-20 11:13 ` Marcel Apfelbaum
2016-06-17 9:37 ` Dr. David Alan Gilbert
2016-06-17 9:54 ` Paolo Bonzini
2016-06-17 13:18 ` Eduardo Habkost
2016-06-17 13:38 ` Paolo Bonzini
2016-06-17 15:19 ` Eduardo Habkost
2016-06-17 15:28 ` Paolo Bonzini
2016-06-17 15:49 ` Eduardo Habkost
2016-06-21 19:44 ` [Qemu-devel] Default for phys-addr-bits? (was Re: [PATCH 4/5] x86: Allow physical address bits to be set) Eduardo Habkost
2016-06-22 12:41 ` Paolo Bonzini
2016-06-22 14:24 ` Andrea Arcangeli
2016-06-22 14:33 ` Paolo Bonzini
2016-06-22 14:44 ` Andrea Arcangeli
2016-06-22 14:48 ` Paolo Bonzini
2016-06-22 15:02 ` Andrea Arcangeli
2016-06-22 22:44 ` Michael S. Tsirkin
2016-06-22 23:23 ` Andrea Arcangeli
2016-06-22 23:45 ` Michael S. Tsirkin
2016-06-23 8:40 ` Gerd Hoffmann
2016-06-23 16:38 ` Michael S. Tsirkin
2016-06-24 5:55 ` Gerd Hoffmann
2016-06-24 23:12 ` Michael S. Tsirkin
2016-06-29 16:42 ` Dr. David Alan Gilbert
2016-06-30 6:10 ` Gerd Hoffmann
2016-06-30 10:59 ` Dr. David Alan Gilbert
2016-06-30 16:14 ` Gerd Hoffmann
2016-06-30 17:12 ` Dr. David Alan Gilbert [this message]
2016-07-01 19:03 ` Dr. David Alan Gilbert
2016-06-22 22:40 ` Michael S. Tsirkin
2016-06-22 23:15 ` Andrea Arcangeli
2016-06-19 3:36 ` [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set Michael S. Tsirkin
2016-06-20 7:04 ` Paolo Bonzini
2016-06-17 14:24 ` Marcel Apfelbaum
2016-06-16 17:12 ` [Qemu-devel] [PATCH 5/5] x86: Set physical address bits based on host Dr. David Alan Gilbert (git)
2016-06-17 7:25 ` Igor Mammedov
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=20160630171233.GE2683@work-vm \
--to=dgilbert@redhat.com \
--cc=aarcange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@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 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.