qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Jordan Justen (Intel address)" <jordan.l.justen@intel.com>,
	qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
	Anthony Liguori <aliguori@amazon.com>
Subject: Re: [Qemu-devel] [PULL for-1.8 1/2] pc: disable pci-info
Date: Tue, 26 Nov 2013 19:58:55 +0100	[thread overview]
Message-ID: <20131126195855.0064888d@thinkpad> (raw)
In-Reply-To: <5294ABF5.4090405@redhat.com>

On Tue, 26 Nov 2013 15:11:01 +0100
Laszlo Ersek <lersek@redhat.com> wrote:

> On 11/26/13 10:10, Michael S. Tsirkin wrote:
> 
> > seabios manages to enumerate PCI with information exported from qemu
> > so why can't OVMF?
> 
> SeaBIOS and qemu duplicate logic (code) between each other.
> 
> src/fw/pciinit.c grabs RamSize over fw_cfg, and i440fx_mem_addr_setup()
> sets "pcimem_start" to one of three values based on RamSize. (One of the
> three is not explicit there, it's the build default 0xe0000000.)
> 
> The same code is visible in qemu in i440fx_init().
> 
> I duplicated the same logic in OVMF's PEI one week ago, and it solved
> the problem. See the patch attached to
> <http://thread.gmane.org/gmane.comp.bios.tianocore.devel/4881/focus=4995>.
> 
> But code/logic duplication is ugly, which is why I've been looking for a
> better, dynamic solution ever since.
> 
> > I think it's down to other qemu bugs (such as _CRS not covering
> > all of PCI memory), we shall just fix them.
> 
> I don't know how to fix them. I don't know how to enumerate all PCI
> regions in use, plus all unassigned ranges, from below, like with a
> MemoryListener.
> 
> If I understand correctly, Igor suggested to track devices as they map
> their regions, but (again, if I understood correctly) you didn't seem to
> like the idea.
Let me try to summarize what could be done:
 - let all not mapped area fall through to PCI address space (queued for 1.8
   on pci branch)
 - drop pci_info in QEMU completely (including variable/field)
 - during ACPI tables building find all not mapped/reserved regions in e820 map
   (that should take care about all present hardware)
   and create corresponding CRSes.
   there are caveats here:
     * Q35 can add/update mmconfig reservation in e820 table when programmed,
       so scanner won't have to know about it.
     * WS2003/XP case: it doesn't like 64-PCI windows CRS, so corresponding CRS
       shouldn't be created if there isn't any BARs there.
     * take care about explicit/forced creation of 64-bit PCI window CRS for
       PCI hotplug.
     * I don't know how to punch holes in PCI windows for BIOS originated
       reservations. (it's reverse problem, now we need BIOS update QEMU ACPI
       tables). Probably there is no need for it but I don't know SeaBIOS well
       enough.

> Thanks
> Laszlo
> 


-- 
Regards,
  Igor

  reply	other threads:[~2013-11-26 18:59 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-18 11:53 [Qemu-devel] [PULL for-1.8 0/2] pc last minute fixes for 1.8 Michael S. Tsirkin
2013-11-18 11:53 ` [Qemu-devel] [PULL for-1.8 1/2] pc: disable pci-info Michael S. Tsirkin
2013-11-26  8:12   ` Laszlo Ersek
2013-11-26  9:10     ` Michael S. Tsirkin
2013-11-26 11:00       ` Gerd Hoffmann
2013-11-26 14:04         ` Michael S. Tsirkin
2013-11-26 14:22           ` Laszlo Ersek
2013-11-26 15:04             ` Michael S. Tsirkin
2013-11-26 15:42             ` Gerd Hoffmann
2013-11-26 15:48               ` Michael S. Tsirkin
2013-11-26 18:26               ` Igor Mammedov
2013-11-27  6:15                 ` Michael S. Tsirkin
2013-11-26 15:20           ` Gerd Hoffmann
2013-11-26 15:28             ` Michael S. Tsirkin
2013-11-26 15:59               ` Gerd Hoffmann
2013-11-27  6:20                 ` Michael S. Tsirkin
2013-11-26 14:11       ` Laszlo Ersek
2013-11-26 18:58         ` Igor Mammedov [this message]
2013-11-18 11:53 ` [Qemu-devel] [PULL for-1.8 2/2] doc: fix hardcoded helper path Michael S. Tsirkin
2013-11-18 15:06 ` [Qemu-devel] [PULL for-1.8 0/2] pc last minute fixes for 1.8 Eric Blake
2013-11-18 15:17   ` 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=20131126195855.0064888d@thinkpad \
    --to=imammedo@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=ehabkost@redhat.com \
    --cc=jordan.l.justen@intel.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mst@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 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).