qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL for-1.8 1/2] pc: disable pci-info


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PULL for-1.8 1/2] pc: disable pci-info
Date: Tue, 26 Nov 2013 19:58:55 +0100

On Tue, 26 Nov 2013 15:11:01 +0100
Laszlo Ersek <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]