2017-08-08 18:11 GMT+03:00 Laszlo Ersek <ler...@redhat.com>: > one comment below > > On 08/05/17 22:27, Aleksandr Bezzubikov wrote: > >> +Capability layout (defined in include/hw/pci/pci_bridge.h): >> + >> + uint8_t id; Standard PCI capability header field >> + uint8_t next; Standard PCI capability header field >> + uint8_t len; Standard PCI vendor-specific capability header field >> + >> + uint8_t type; Red Hat vendor-specific capability type >> + List of currently existing types: >> + QEMU_RESERVE = 1 >> + >> + >> + uint32_t bus_res; Minimum number of buses to reserve >> + >> + uint64_t io; IO space to reserve >> + uint64_t mem Non-prefetchable memory to reserve >> + uint64_t mem_pref; Prefetchable memory to reserve > > (I apologize if I missed any concrete points from the past messages > regarding this structure.) > > How is the firmware supposed to know whether the prefetchable MMIO > reservation should be made in 32-bit or 64-bit address space? If we > reserve prefetchable MMIO outside of the 32-bit address space, then > hot-plugging a device without 64-bit MMIO support could fail. > > My earlier request, to distinguish "prefetchable_32" from > "prefetchable_64" (mutually exclusively), was so that firmware would > know whether to restrict the MMIO reservation to 32-bit address space.
IIUC now (in SeaBIOS at least) we just assign this PREF registers unconditionally, so the decision about the mode can be made basing on !=0 UPPER_PREF_LIMIT register. My idea was the same - we can just check if the value doesn't fit into 16-bit (PREF_LIMIT reg size, 32-bit MMIO). Do we really need separate fields for that? > > This is based on an earlier email from Alex to me: > > On 10/03/16 18:01, Alex Williamson wrote: >> I don't think there's such a thing as a 64-bit non-prefetchable >> aperture. In fact, there are not separate 32 and 64 bit prefetchable >> apertures. The apertures are: >> >> I/O base/limit - (default 16bit, may be 32bit) >> Memory base/limit - (32bit only, non-prefetchable) >> Prefetchable Memory base/limit - (default 32bit, may be 64bit) >> >> This is according to Table 3-2 in the PCI-to-PCI bridge spec rev 1.2. > > I don't care much about the 16-bit vs. 32-bit IO difference (that's > entirely academic and the Platform Spec init doesn't even provide a way > for OVMF to express such a difference). However, the optional > restriction to 32-bit matters for the prefetchable MMIO aperture. > > Other than this, the patch looks good to me, and I'm ready to R-b. > > Thanks! > Laszlo -- Aleksandr Bezzubikov
