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: Thu, 30 Jun 2016 11:59:09 +0100	[thread overview]
Message-ID: <20160630105908.GA2683@work-vm> (raw)
In-Reply-To: <1467267046.15123.94.camel@redhat.com>

* Gerd Hoffmann (kraxel@redhat.com) wrote:
>   Hi,
> 
> > Something somewhere in qemu/ kernel/ firmware is already reading the number
> > of physical bits to determine PCI mapping; if I do:
> > 
> > ./x86_64-softmmu/qemu-system-x86_64 -m 4096,slots=16,maxmem=128T
> 
> No, it's not the physbits.  You add some memory hotplug slots here.
> Qemu will ask seabios to reserve address space for those, which seabios
> promptly does and maps 64bit pci bars above the reserved address space.

Right, that's what I was trying to do - I wanted to see if I could get something
to use the non-existing address space.

> >    -vga none -device qxl-vga,bus=pcie.0,ram_size_mb=2048,vram64_size_mb=2048 -vnc 0.0.0.0:0 /home/vms/7.2a.qcow2 -chardev stdio,mux=on,id=mon -mon chardev=mon,mode=readline -cpu host,phys-bits=48
> > 
> > it will happily map the qxl VRAM right up high, but if I lower
> > the phys-bits down to 46 it won't.
> 
> I suspect the linux kernel remaps the bar because the seabios mapping is
> unreachable.  Check dmesg.

Right, and that is dependent on physbits; if I run with:

./x86_64-softmmu/qemu-system-x86_64 -machine q35,accel=kvm,usb=off -m 4096,slots=16,maxmem=128T   -vga none -device qxl-vga,bus=pcie.0,ram_size_mb=2048,vram64_size_mb=2048 -vnc 0.0.0.0:0 /home/vms/7.2a.qcow2 -chardev stdio,mux=on,id=mon -mon chardev=mon,mode=readline -cpu host,phys-bits=48
  (on a 46 bit xeon) it happily maps that 64-bit bar into somewhere
that shouldn't be accessible:

[    0.266183] pci_bus 0000:00: root bus resource [mem 0x800480000000-0x8004ffffffff]
[    0.321611] pci 0000:00:02.0: reg 0x20: [mem 0x800480000000-0x8004ffffffff 64bit pref]
[    0.423257] pci_bus 0000:00: resource 8 [mem 0x800480000000-0x8004ffffffff]

lspci -v:

00:02.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04) (prog-if 00 [VGA controller])
	Subsystem: Red Hat, Inc QEMU Virtual Machine
	Flags: fast devsel, IRQ 22
	Memory at c0000000 (32-bit, non-prefetchable) [size=512M]
	Memory at e0000000 (32-bit, non-prefetchable) [size=64M]
	Memory at e4070000 (32-bit, non-prefetchable) [size=8K]
	I/O ports at c080 [size=32]
	Memory at 800480000000 (64-bit, prefetchable) [size=2G]
	Expansion ROM at e4060000 [disabled] [size=64K]
	Kernel driver in use: qxl

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?

If I change the phys-bits=48 to 46 the kernel avoids it:
    [    0.414867] acpi PNP0A08:00: host bridge window [0x800480000000-0x8004ffffffff] (ignored, not CPU addressable)
    [    0.683134] pci 0000:00:02.0: can't claim BAR 4 [mem 0x800480000000-0x8004ffffffff 64bit pref]: no compatible bridge window
    [    0.703948] pci 0000:00:02.0: BAR 4: [mem size 0x80000000 64bit pref] conflicts with PCI mem [mem 0x00000000-0x3fffffffffff]
    [    0.703951] pci 0000:00:02.0: BAR 4: failed to assign [mem size 0x80000000 64bit pref]

lspci shows:
    Memory at <ignored> (64-bit, prefetchable)

(Although interesting qemu's info pci still shows it).

The 'ignored, not CPU addressable' comes from the kernel's drivers/acpi/pci_root.c acpi_pci_root_validate_resources
that uses a value set in arch/x86/kernel/setup.c:
    iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;

So at least the Linux kernel does sanity check using the phys_bits value.

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).

Still, this only hits as a problem if you hit the combination of:
   a) You use large PCI bars
   b) On a 36/39/40bit host
   c) With a large maxmem that forces those PCI bars up to something silly.

Dave

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

  reply	other threads:[~2016-06-30 10:59 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 [this message]
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
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=20160630105908.GA2683@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.