[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 5/5] docs: update documentation considering P
From: |
Aleksandr Bezzubikov |
Subject: |
Re: [Qemu-devel] [PATCH v4 5/5] docs: update documentation considering PCIE-PCI bridge |
Date: |
Tue, 8 Aug 2017 22:21:59 +0300 |
2017-08-08 18:11 GMT+03:00 Laszlo Ersek <address@hidden>:
> 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