2017-08-08 18:11 GMT+03:00 Laszlo Ersek lersek@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