All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 1 Jul 2016 20:03:54 +0100	[thread overview]
Message-ID: <20160701190354.GB29394@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.
> 
> > 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.

OK, yes I got that working, and you're right, it does map it high;
(with recent OVMF running virtio 1.0, that needed recent guest/host kernels)
and it does fail easily as well if memory doesn't fit, so for
example:

(all on a xeon with 46 bit physical host)

specifying maxmem=1T - upstream build is hanging - but works if I specify phys-bits=46
    so yes, it's noticing if the guest phys-bits is too small
    even if the host can manage it.

It's OK if running with small amount of RAM and phys-bits=40

maxmem=64T with any phys-bits hangs.


specifying maxmem=64T with phys-bits=46 on xeon and it hangs
specifying maxmem=64T with phys-bits=48 on xeon and it hangs
specifying maxmem=32T with phys-bits=46-48 on xeon and it works

So for example we see:
  Bus  2, device   4, function 0:
    SCSI controller: PCI device 1af4:1042
      IRQ 10.
      BAR1: 32 bit memory at 0x98000000 [0x98000fff].
      BAR4: 64 bit prefetchable memory at 0x200800000000 [0x2008007fffff].
      id "virtio-disk0"

  and that works nicely.

Dave

> 
> cheers,
>   Gerd
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

  parent reply	other threads:[~2016-07-01 19:04 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
2016-07-01 19:03                                       ` Dr. David Alan Gilbert [this message]
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=20160701190354.GB29394@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.