* Gerd Hoffmann (kra...@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 / dgilb...@redhat.com / Manchester, UK
