From: Marcel Apfelbaum <marcel@redhat.com>
To: Aleksandr Bezzubikov <zuban32s@gmail.com>, seabios@seabios.org
Cc: mst@redhat.com, kevin@koconnor.net, lersek@redhat.com,
qemu-devel@nongnu.org, kraxel@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 2/3] pci: add QEMU-specific PCI capability structure
Date: Mon, 31 Jul 2017 13:48:27 +0300 [thread overview]
Message-ID: <3a4e727a-b7ee-66b6-913e-4eb7eef8fa36@redhat.com> (raw)
In-Reply-To: <1501284872-2078-3-git-send-email-zuban32s@gmail.com>
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 <zuban32s@gmail.com>
> ---
> 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
next prev parent reply other threads:[~2017-07-31 10:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 23:34 [Qemu-devel] [PATCH v3 0/3] Allow RedHat PCI bridges reserve more buses than necessary during init Aleksandr Bezzubikov
2017-07-28 23:34 ` [Qemu-devel] [PATCH v3 1/3] pci: refactor pci_find_capapibilty to get bdf as the first argument instead of the whole pci_device Aleksandr Bezzubikov
2017-07-28 23:34 ` [Qemu-devel] [PATCH v3 2/3] pci: add QEMU-specific PCI capability structure Aleksandr Bezzubikov
2017-07-31 10:48 ` Marcel Apfelbaum [this message]
2017-07-31 14:00 ` Michael S. Tsirkin
2017-07-31 14:09 ` Marcel Apfelbaum
2017-07-31 18:54 ` Alexander Bezzubikov
2017-07-31 18:57 ` Michael S. Tsirkin
2017-07-31 19:01 ` Alexander Bezzubikov
2017-08-01 13:38 ` Marcel Apfelbaum
2017-08-01 17:28 ` Alexander Bezzubikov
2017-08-04 18:59 ` Alexander Bezzubikov
2017-08-04 20:28 ` Laszlo Ersek
2017-08-04 20:47 ` Alexander Bezzubikov
2017-08-06 19:58 ` Marcel Apfelbaum
2017-07-28 23:34 ` [Qemu-devel] [PATCH v3 3/3] pci: enable RedHat PCI bridges to reserve additional buses on PCI init Aleksandr Bezzubikov
2017-07-31 11:00 ` Marcel Apfelbaum
2017-07-31 13:50 ` Kevin O'Connor
2017-07-31 13:56 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a4e727a-b7ee-66b6-913e-4eb7eef8fa36@redhat.com \
--to=marcel@redhat.com \
--cc=kevin@koconnor.net \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=seabios@seabios.org \
--cc=zuban32s@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).