From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>
Cc: qemu-devel@nongnu.org,
Alex Williamson <alex.williamson@redhat.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
David Gibson <david@gibson.dropbear.id.au>,
anthony@codemonkey.ws, kvm@vger.kernel.org
Subject: Re: [RFC PATCH] qemu pci: pci_add_capability enhancement to prevent damaging config space
Date: Fri, 11 May 2012 22:47:11 +1000 [thread overview]
Message-ID: <4FAD0A4F.2050506@ozlabs.ru> (raw)
In-Reply-To: <6A22E211-BC82-49BD-A335-02D3BAA14A17@suse.de>
11.05.2012 20:52, Alexander Graf написал:
>
> On 11.05.2012, at 08:45, Alexey Kardashevskiy wrote:
>
>> Normally the pci_add_capability is called on devices to add new
>> capability. This is ok for emulated devices which capabilities list
>> is being built by QEMU.
>>
>> In the case of VFIO the capability may already exist and adding new
>> capability into the beginning of the linked list may create a loop.
>>
>> For example, the old code destroys the following config
>> of PCIe Intel E1000E:
>>
>> before adding PCI_CAP_ID_MSI (0x05):
>> 0x34: 0xC8
>> 0xC8: 0x01 0xD0
>> 0xD0: 0x05 0xE0
>> 0xE0: 0x10 0x00
>>
>> after:
>> 0x34: 0xD0
>> 0xC8: 0x01 0xD0
>> 0xD0: 0x05 0xC8
>> 0xE0: 0x10 0x00
>>
>> As result capabilities 0x01 and 0x05 point to each other.
>>
>> The proposed patch does not change capability pointers when
>> the same type capability is about to add.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> hw/pci.c | 10 ++++++----
>> 1 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/pci.c b/hw/pci.c
>> index aa0c0b8..1f7c924 100644
>> --- a/hw/pci.c
>> +++ b/hw/pci.c
>> @@ -1794,10 +1794,12 @@ int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
>> }
>>
>> config = pdev->config + offset;
>> - config[PCI_CAP_LIST_ID] = cap_id;
>> - config[PCI_CAP_LIST_NEXT] = pdev->config[PCI_CAPABILITY_LIST];
>> - pdev->config[PCI_CAPABILITY_LIST] = offset;
>> - pdev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
>> + if (config[PCI_CAP_LIST_ID] != cap_id) {
>
> This doesn't scale. Capabilities are a list of CAPs. You'll have to do a loop through all capabilities, check if the one you want to add is there already and if so either
> * replace the existing one or
> * drop out and not write the new one in.
>
> I'm not sure which way would be more natural.
There is a third option - add another function, lets call it
pci_fixup_capability() which would do whatever pci_add_capability() does
but won't touch list pointers.
When vfio, pci_add_capability() is called from the code which knows
exactly that the capability exists and where it is and it calls
pci_add_capability() based on this knowledge so doing additional loops
just for imaginery scalability is a bit weird, no?
>> + config[PCI_CAP_LIST_ID] = cap_id;
>> + config[PCI_CAP_LIST_NEXT] = pdev->config[PCI_CAPABILITY_LIST];
>> + pdev->config[PCI_CAPABILITY_LIST] = offset;
>> + pdev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
>> + }
>> memset(pdev->used + offset, 0xFF, size);
>> /* Make capability read-only by default */
>> memset(pdev->wmask + offset, 0, size);
--
With best regards
Alexey Kardashevskiy
WARNING: multiple messages have this Message-ID (diff)
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Alexander Graf <agraf@suse.de>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
Alex Williamson <alex.williamson@redhat.com>,
anthony@codemonkey.ws, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [RFC PATCH] qemu pci: pci_add_capability enhancement to prevent damaging config space
Date: Fri, 11 May 2012 22:47:11 +1000 [thread overview]
Message-ID: <4FAD0A4F.2050506@ozlabs.ru> (raw)
In-Reply-To: <6A22E211-BC82-49BD-A335-02D3BAA14A17@suse.de>
11.05.2012 20:52, Alexander Graf написал:
>
> On 11.05.2012, at 08:45, Alexey Kardashevskiy wrote:
>
>> Normally the pci_add_capability is called on devices to add new
>> capability. This is ok for emulated devices which capabilities list
>> is being built by QEMU.
>>
>> In the case of VFIO the capability may already exist and adding new
>> capability into the beginning of the linked list may create a loop.
>>
>> For example, the old code destroys the following config
>> of PCIe Intel E1000E:
>>
>> before adding PCI_CAP_ID_MSI (0x05):
>> 0x34: 0xC8
>> 0xC8: 0x01 0xD0
>> 0xD0: 0x05 0xE0
>> 0xE0: 0x10 0x00
>>
>> after:
>> 0x34: 0xD0
>> 0xC8: 0x01 0xD0
>> 0xD0: 0x05 0xC8
>> 0xE0: 0x10 0x00
>>
>> As result capabilities 0x01 and 0x05 point to each other.
>>
>> The proposed patch does not change capability pointers when
>> the same type capability is about to add.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> hw/pci.c | 10 ++++++----
>> 1 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/pci.c b/hw/pci.c
>> index aa0c0b8..1f7c924 100644
>> --- a/hw/pci.c
>> +++ b/hw/pci.c
>> @@ -1794,10 +1794,12 @@ int pci_add_capability(PCIDevice *pdev, uint8_t cap_id,
>> }
>>
>> config = pdev->config + offset;
>> - config[PCI_CAP_LIST_ID] = cap_id;
>> - config[PCI_CAP_LIST_NEXT] = pdev->config[PCI_CAPABILITY_LIST];
>> - pdev->config[PCI_CAPABILITY_LIST] = offset;
>> - pdev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
>> + if (config[PCI_CAP_LIST_ID] != cap_id) {
>
> This doesn't scale. Capabilities are a list of CAPs. You'll have to do a loop through all capabilities, check if the one you want to add is there already and if so either
> * replace the existing one or
> * drop out and not write the new one in.
>
> I'm not sure which way would be more natural.
There is a third option - add another function, lets call it
pci_fixup_capability() which would do whatever pci_add_capability() does
but won't touch list pointers.
When vfio, pci_add_capability() is called from the code which knows
exactly that the capability exists and where it is and it calls
pci_add_capability() based on this knowledge so doing additional loops
just for imaginery scalability is a bit weird, no?
>> + config[PCI_CAP_LIST_ID] = cap_id;
>> + config[PCI_CAP_LIST_NEXT] = pdev->config[PCI_CAPABILITY_LIST];
>> + pdev->config[PCI_CAPABILITY_LIST] = offset;
>> + pdev->config[PCI_STATUS] |= PCI_STATUS_CAP_LIST;
>> + }
>> memset(pdev->used + offset, 0xFF, size);
>> /* Make capability read-only by default */
>> memset(pdev->wmask + offset, 0, size);
--
With best regards
Alexey Kardashevskiy
next prev parent reply other threads:[~2012-05-11 12:47 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-11 6:45 [RFC PATCH] qemu pci: pci_add_capability enhancement to prevent damaging config space Alexey Kardashevskiy
2012-05-11 6:45 ` [Qemu-devel] " Alexey Kardashevskiy
2012-05-11 10:52 ` Alexander Graf
2012-05-11 10:52 ` [Qemu-devel] " Alexander Graf
2012-05-11 12:47 ` Alexey Kardashevskiy [this message]
2012-05-11 12:47 ` Alexey Kardashevskiy
2012-05-11 14:13 ` Alexander Graf
2012-05-11 14:13 ` [Qemu-devel] " Alexander Graf
2012-05-14 3:49 ` Alexey Kardashevskiy
2012-05-14 3:49 ` [Qemu-devel] " Alexey Kardashevskiy
2012-05-18 5:12 ` Alexey Kardashevskiy
2012-05-18 5:12 ` [Qemu-devel] " Alexey Kardashevskiy
2012-05-22 2:02 ` Benjamin Herrenschmidt
2012-05-22 2:02 ` [Qemu-devel] " Benjamin Herrenschmidt
2012-05-22 3:21 ` Alexander Graf
2012-05-22 3:21 ` [Qemu-devel] " Alexander Graf
2012-05-22 3:44 ` Alexey Kardashevskiy
2012-05-22 3:44 ` [Qemu-devel] " Alexey Kardashevskiy
2012-05-22 5:52 ` Alexander Graf
2012-05-22 5:52 ` [Qemu-devel] " Alexander Graf
2012-05-22 6:11 ` Alexey Kardashevskiy
2012-05-22 6:11 ` [Qemu-devel] " Alexey Kardashevskiy
2012-05-22 6:31 ` Alexander Graf
2012-05-22 6:31 ` [Qemu-devel] " Alexander Graf
2012-05-22 7:01 ` Alexey Kardashevskiy
2012-05-22 7:01 ` [Qemu-devel] " Alexey Kardashevskiy
2012-05-22 7:13 ` Alexander Graf
2012-05-22 7:13 ` [Qemu-devel] " Alexander Graf
2012-05-22 7:37 ` Benjamin Herrenschmidt
2012-05-22 7:37 ` [Qemu-devel] " Benjamin Herrenschmidt
2012-06-08 8:47 ` Alexey Kardashevskiy
2012-06-08 8:47 ` [Qemu-devel] " Alexey Kardashevskiy
2012-06-08 10:56 ` Jan Kiszka
2012-06-08 10:56 ` [Qemu-devel] " Jan Kiszka
2012-06-08 11:16 ` Alexey Kardashevskiy
2012-06-08 11:16 ` [Qemu-devel] " Alexey Kardashevskiy
2012-06-08 11:30 ` Jan Kiszka
2012-06-08 11:30 ` [Qemu-devel] " Jan Kiszka
2012-06-08 14:00 ` Alexey Kardashevskiy
2012-06-08 14:00 ` [Qemu-devel] " Alexey Kardashevskiy
2012-06-08 14:43 ` Jan Kiszka
2012-06-08 14:43 ` [Qemu-devel] " Jan Kiszka
2012-06-08 14:56 ` Alex Williamson
2012-06-08 14:56 ` [Qemu-devel] " Alex Williamson
2012-06-08 15:05 ` Jan Kiszka
2012-06-08 15:05 ` [Qemu-devel] " Jan Kiszka
2012-06-08 15:22 ` Alex Williamson
2012-06-08 15:22 ` [Qemu-devel] " Alex Williamson
2012-05-22 6:38 ` Alexander Graf
2012-05-22 6:38 ` [Qemu-devel] " Alexander Graf
2012-05-11 19:20 ` Jason Baron
2012-05-11 19:20 ` [Qemu-devel] " Jason Baron
2012-05-12 0:27 ` Alexey Kardashevskiy
2012-05-12 0:27 ` Alexey Kardashevskiy
2012-05-14 2:37 ` Alex Williamson
2012-05-14 2:37 ` Alex Williamson
-- strict thread matches above, loose matches on Subject: below --
2012-05-11 6:59 Alexey Kardashevskiy
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=4FAD0A4F.2050506@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=benh@kernel.crashing.org \
--cc=david@gibson.dropbear.id.au \
--cc=kvm@vger.kernel.org \
--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.