Re: [SeaBIOS] [PATCH v3 2/3] pci: add QEMU-specific PCI capability structure

[Marcel Apfelbaum]

On 29/07/2017 2:34, Aleksandr Bezzubikov wrote:
> On PCI init PCI bridge devices may need some
> extra info about bus number to reserve, IO, memory and
> prefetchable memory limits. QEMU can provide this
> with special vendor-specific PCI capability.
>
> This capability is intended to be used only
> for Red Hat PCI bridges, i.e. QEMU cooperation.
> Signed-off-by: Aleksandr Bezzubikov
>
> src/fw/dev-pci.h | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 62 insertions(+)
>   create mode 100644 src/fw/dev-pci.h
>
> diff --git a/src/fw/dev-pci.h b/src/fw/dev-pci.h
> new file mode 100644
> index 0000000..fbd49ed
> --- /dev/null
> +++ b/src/fw/dev-pci.h
> @@ -0,0 +1,62 @@
> +#ifndef _PCI_CAP_H
> +#define _PCI_CAP_H
>
> +#include "types.h"
>
> +/*

Hi Aleksander,
> +QEMU-specific vendor(Red Hat)-specific capability.
> +It's intended to provide some hints for firmware to init PCI devices.
>
> +Its is shown below:
>
> +Header:
>
> +u8 id;       Standard PCI Capability Header field
> +u8 next;     Standard PCI Capability Header field
> +u8 len;      Standard PCI Capability Header field
> +u8 type;     Red Hat vendor-specific capability type:
>           now only REDHAT_QEMU_CAP 1 exists
>
> +Data:
>
> +u16 non_prefetchable_16;     non-prefetchable memory limit

Maybe we should name it "mem". And if I remember right Gerd
suggested keeping them all 32 bits:

u32 mem_res
> +u8 bus_res;  minimum bus number to reserve;
>         this is necessary for PCI Express Root Ports
>         to support PCIE-to-PCI bridge hotplug
>
> +u8 io_8;     IO limit in case of 8-bit limit value

I must have missed it, but why do we need io_8 field?
> +u32 io_32;   IO limit in case of 16-bit limit value
>         io_8 and io_16 are mutually exclusive, in other words,
>         they can't be non-zero simultaneously

I don't see any io_16 field.
Maybe only one field:
   u32 io_res
> +u32 prefetchable_32;         non-prefetchable memory limit
>                         in case of 32-bit limit value

Name and comment mismatch
> +u64 prefetchable_64;         non-prefetchable memory limit
>                         in case of 64-bit limit value
>                         prefetachable_32 and prefetchable_64 are
>                         mutually exclusive, in other words,
>                         they can't be non-zero simultaneously

Name and comment mismatch

It should look like:
         - u32 bus_res
         - u32 io_res
         - u32 mem_res,
         - u32 mem_prefetchable_32,
         - u64 mem_prefetchable_64, (mutually exclusive with the above)

Does it look right to all?
> +If any field in Data section is 0,
> +it means that such kind of reservation
> +is not needed.
>
> +*/
>
> +/* Offset of vendor-specific capability type field */
> +#define PCI_CAP_VNDR_SPEC_TYPE  3
>
> +/* List of valid Red Hat vendor-specific capability types */
> +#define REDHAT_CAP_TYPE_QEMU    1

Maybe we should be more concrete:
   REDHAT_CAP_TYPE_RES_RESERVE
> +/* Offsets of QEMU capability fields */
> +#define QEMU_PCI_CAP_NON_PREF   4
> +#define QEMU_PCI_CAP_BUS_RES    6
> +#define QEMU_PCI_CAP_IO_8       7
> +#define QEMU_PCI_CAP_IO_32      8
> +#define QEMU_PCI_CAP_PREF_32    12
> +#define QEMU_PCI_CAP_PREF_64    16
> +#define QEMU_PCI_CAP_SIZE       24
>
> +#endif /* _PCI_CAP_H */

I know the exact layout is less important for your current
project, but is important to get it right the first time.

Thanks,
Marcel