From: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
To: Cao jin <caoj.fnst@cn.fujitsu.com>, qemu-devel@nongnu.org
Cc: chen.fan.fnst@cn.fujitsu.com, izumi.taku@jp.fujitsu.com,
alex.williamson@redhat.com, mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH v16 05/14] vfio: add pcie extanded capability support
Date: Sun, 17 Jan 2016 15:22:37 +0200 [thread overview]
Message-ID: <569B959D.9080206@gmail.com> (raw)
In-Reply-To: <093036e6a4398c01ba4ead12cd064932087e3da7.1452564770.git.chen.fan.fnst@cn.fujitsu.com>
On 01/12/2016 04:43 AM, Cao jin wrote:
> From: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
>
Hi,
I noticed a type in the subject, extanded -> extended
> For vfio pcie device, we could expose the extended capability on
> PCIE bus. in order to avoid config space broken, we introduce
> a copy config for parsing extended caps. and rebuild the pcie
> extended config space.
Maybe we can re-word this. Will someone with better English skills
advice :) ?
>
> Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
> ---
> hw/vfio/pci.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 69 insertions(+), 1 deletion(-)
>
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 288f2c7..64b0867 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -1482,6 +1482,21 @@ static uint8_t vfio_std_cap_max_size(PCIDevice *pdev, uint8_t pos)
> return next - pos;
> }
>
> +
> +static uint16_t vfio_ext_cap_max_size(const uint8_t *config, uint16_t pos)
> +{
> + uint16_t tmp, next = PCIE_CONFIG_SPACE_SIZE;
> +
> + for (tmp = PCI_CONFIG_SPACE_SIZE; tmp;
> + tmp = PCI_EXT_CAP_NEXT(pci_get_long(config + tmp))) {
> + if (tmp > pos && tmp < next) {
> + next = tmp;
> + }
> + }
> +
> + return next - pos;
> +}
Can't we reuse vfio_std_cap_max_size here? if only the config size differs,
we can pass it as parameter.
> +
> static void vfio_set_word_bits(uint8_t *buf, uint16_t val, uint16_t mask)
> {
> pci_set_word(buf, (pci_get_word(buf) & ~mask) | val);
> @@ -1817,16 +1832,69 @@ static int vfio_add_std_cap(VFIOPCIDevice *vdev, uint8_t pos)
> return 0;
> }
>
> +static int vfio_add_ext_cap(VFIOPCIDevice *vdev)
> +{
> + PCIDevice *pdev = &vdev->pdev;
> + uint32_t header;
> + uint16_t cap_id, next, size;
> + uint8_t cap_ver;
> + uint8_t *config;
> +
> + /*
> + * In order to avoid breaking config space, create a copy to
> + * use for parsing extended capabilities.
It will be nice to know *how* do we break/*what* will break the config
space, I confess that I didn't see it :(.
> + */
> + config = g_memdup(pdev->config, vdev->config_size);
> +
> + for (next = PCI_CONFIG_SPACE_SIZE; next;
> + next = PCI_EXT_CAP_NEXT(pci_get_long(config + next))) {
> + header = pci_get_long(config + next);
> + cap_id = PCI_EXT_CAP_ID(header);
> + cap_ver = PCI_EXT_CAP_VER(header);
> +
> + /*
> + * If it becomes important to configure extended capabilities to their
> + * actual size, use this as the default when it's something we don't
> + * recognize. Since QEMU doesn't actually handle many of the config
> + * accesses, exact size doesn't seem worthwhile.
> + */
> + size = vfio_ext_cap_max_size(config, next);
> +
> + pcie_add_capability(pdev, cap_id, cap_ver, next, size);
> + pci_set_long(dev->config + next, PCI_EXT_CAP(cap_id, cap_ver, 0));
> +
> + /* Use emulated next pointer to allow dropping extended caps */
> + pci_long_test_and_set_mask(vdev->emulated_config_bits + next,
> + PCI_EXT_CAP_NEXT_MASK);
> + }
> +
> + g_free(config);
> + return 0;
> +}
> +
> static int vfio_add_capabilities(VFIOPCIDevice *vdev)
> {
> PCIDevice *pdev = &vdev->pdev;
> + int ret;
>
> if (!(pdev->config[PCI_STATUS] & PCI_STATUS_CAP_LIST) ||
> !pdev->config[PCI_CAPABILITY_LIST]) {
> return 0; /* Nothing to add */
> }
>
> - return vfio_add_std_cap(vdev, pdev->config[PCI_CAPABILITY_LIST]);
> + ret = vfio_add_std_cap(vdev, pdev->config[PCI_CAPABILITY_LIST]);
> + if (ret) {
> + return ret;
> + }
> +
> + /* on PCI bus, it doesn't make sense to expose extended capabilities. */
> + if (!pci_is_express(pdev) ||
> + !pci_bus_is_express(pdev->bus) ||
> + !pci_get_long(pdev->config + PCI_CONFIG_SPACE_SIZE)) {
I am curious about the last check, "!pci_get_long(pdev->config + PCI_CONFIG_SPACE_SIZE)",
can you please explain?
Thank you,
Marcel
> + return 0;
> + }
> +
> + return vfio_add_ext_cap(vdev);
> }
>
> static void vfio_pci_pre_reset(VFIOPCIDevice *vdev)
>
next prev parent reply other threads:[~2016-01-17 13:22 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-12 2:43 [Qemu-devel] [PATCH v16 00/14] vfio-pci: pass the aer error to guest Cao jin
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 01/14] vfio: extract vfio_get_hot_reset_info as a single function Cao jin
2016-01-17 12:48 ` Marcel Apfelbaum
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 02/14] vfio: squeeze out vfio_pci_do_hot_reset for support bus reset Cao jin
2016-01-17 13:01 ` Marcel Apfelbaum
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 03/14] pcie: modify the capability size assert Cao jin
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 04/14] vfio: make the 4 bytes aligned for capability size Cao jin
2016-01-17 12:30 ` Marcel Apfelbaum
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 05/14] vfio: add pcie extanded capability support Cao jin
2016-01-17 13:22 ` Marcel Apfelbaum [this message]
2016-01-19 9:44 ` Chen Fan
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 06/14] aer: impove pcie_aer_init to support vfio device Cao jin
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 07/14] vfio: add aer support for " Cao jin
2016-01-18 9:12 ` Marcel Apfelbaum
2016-01-19 9:47 ` Chen Fan
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 08/14] vfio: add check host bus reset is support or not Cao jin
2016-01-18 10:32 ` Marcel Apfelbaum
2016-01-19 9:55 ` Chen Fan
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 09/14] add check reset mechanism when hotplug vfio device Cao jin
2016-01-18 11:03 ` Marcel Apfelbaum
2016-01-19 1:46 ` Cao jin
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 10/14] pci: introduce pci bus pre reset Cao jin
2016-01-14 20:36 ` Alex Williamson
2016-01-19 10:15 ` Chen Fan
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 11/14] vfio: introduce last reset sequence id Cao jin
2016-01-14 20:43 ` Alex Williamson
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 12/14] pcie_aer: expose pcie_aer_msg() interface Cao jin
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 13/14] vfio-pci: pass the aer error to guest Cao jin
2016-01-18 10:45 ` Marcel Apfelbaum
2016-01-19 9:27 ` Chen Fan
2016-01-12 2:43 ` [Qemu-devel] [PATCH v16 14/14] vfio: add 'aer' property to expose aercap Cao jin
2016-01-18 10:46 ` Marcel Apfelbaum
2016-01-16 18:34 ` [Qemu-devel] [PATCH v16 00/14] vfio-pci: pass the aer error to guest Michael S. Tsirkin
2016-01-19 9:09 ` Chen Fan
2016-02-03 8:54 ` Chen Fan
2016-02-03 13:57 ` Michael S. Tsirkin
2016-02-04 2:04 ` Chen Fan
2016-02-04 11:21 ` Michael S. Tsirkin
2016-02-04 17:46 ` Alex Williamson
2016-02-04 18:09 ` Michael S. Tsirkin
2016-02-04 20:15 ` Alex Williamson
2016-02-04 21:58 ` 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=569B959D.9080206@gmail.com \
--to=marcel.apfelbaum@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=caoj.fnst@cn.fujitsu.com \
--cc=chen.fan.fnst@cn.fujitsu.com \
--cc=izumi.taku@jp.fujitsu.com \
--cc=marcel@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.