[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Mykyta Poturai <Mykyta_Poturai@xxxxxxxx>
- Date: Mon, 2 Nov 2026 13:22:07 +0000
- Accept-language: en-US
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sKrwl1i7LFBa41Q95vHv8rcEwCJBpo3IIyQJ5QBbOkU=; b=S+EeCgiWOzjJmLyUNZ5J1pBMYdBDzN1t7uh3mXzAzMMyjfwvWB5dZNq1qM2/4owwitM8X2W4ewzHsgrg2FkaUHRqnn7br62zqzuP2Jw7hhv7bRRLWKQ0aGLzbaba2yFzSv1qaXyPhE1UaHjvW2rrz6xSUxvQwN3b0u4ukFAgknfT9uIGUgMwRFSkeYdPl6SBlem/6FVe2yxCrmQQIAJkpWkbFHoZU9HHus91tvdCwwsZ0xI+Q9gmfKeSdLxkMZf+d1T1mIaE3bKDrcRRtIT9sQOTOO9EPhJOzJH6dZmaqe7mrqpal08rQUnq9jXVXuCGZaewfJ/lQU1RM904jIToVw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YDx5XiTWvk8GBj61afPoRSDBcOLZowiWPqB0KCpoUmNcvyPHZjs56+JcVsE/wLh3zjNv3evDpQnMAD2I3wXrTxK9WA3WqgP5J6H9M/MnB39aok4y3CT9/WeZCALqVT1qHYoYwX/Lo9ZpHH80Pe0mAYxFYEjBKqs01J/FgoZzP05J4qWnZnhFztho5hrkgW/5IjvF1BQGa1sq6v6OHwm1DHW/I53aH1/blSJ2PX0HGcbQC/3cEBe1wHwJuLcmcX8UH3T7ebKVZsnOxu7TG+fN3aoZ2K+BWQVU7H1u8Ew6OYEIICy4p73oZ1DwK9pRmTnNNLy8egnutmWLkzsFrkLFJQ==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
- Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>, Community Manager <community.manager@xxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 02 Nov 2026 13:22:19 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHdXK6sWnTwG0FjdEmPa5OC537fErcTDN4AgAfUFAA=
- Thread-topic: [PATCH v4 4/5] vpci: add SR-IOV support for PVH Dom0
On 10/28/26 3:49 PM, Jan Beulich wrote:
> On 15.10.2026 16:08, Mykyta Poturai wrote:
>> --- a/CHANGELOG.md
>> +++ b/CHANGELOG.md
>> @@ -16,6 +16,7 @@ The format is based on [Keep a
>> Changelog](https://keepachangelog.com/en/1.0.0/)
>> afterwards.
>>
>> ### Added
>> + - PCI SR-IOV is supported for PVH dom0.
>
> Isn't this x86-only right now?
>
>> --- a/xen/drivers/passthrough/pci.c
>> +++ b/xen/drivers/passthrough/pci.c
>> @@ -32,6 +32,7 @@
>> #include <xen/softirq.h>
>> #include <xen/tasklet.h>
>> #include <xen/vpci.h>
>> +#include <xen/xvmalloc.h>
>> #include <xen/msi.h>
>> #include <xsm/xsm.h>
>> #include "ats.h"
>> @@ -40,6 +41,8 @@ struct pci_seg {
>> struct list_head alldevs_list;
>> u16 nr;
>> unsigned long *ro_map;
>> + /* BDFs of VFs which have been enabled but which Xen has not added yet.
>> */
>> + unsigned long *vf_setup_map;
>> /* bus2bridge_lock protects bus2bridge array */
>> spinlock_t bus2bridge_lock;
>> #define MAX_BUSES 256
>> @@ -139,6 +142,47 @@ const unsigned long *pci_get_ro_map(u16 seg)
>> return pseg ? pseg->ro_map : NULL;
>> }
>>
>> +/*
>> + * Marking is serialised by the hardware domain's pci_lock, which the SR-IOV
>> + * control register write handler holds; unmarking only clears a bit.
>> + */
>
> What about pci_vf_setup_pending()? How's that (to be) serialized again marking
> and unmarking?
>
It isn't. The test runs ahead of any lock because adding the VF takes them.
We could put it under the hardware domain's pci_lock, which is what
control_write() holds for marking and unmarking, but it would have to be
dropped before vpci_sriov_add_vf() anyway: pci_add_device() takes pcidevs_lock,
and the order is pcidevs_lock then pci_lock. So the test and the add can't be
made atomic with the locks we have. Is the lock worth taking just for the bit
test?
The only thing I can see actually misfiring is vf_setup_map: xvzalloc_array()
zeroes it and the pointer store publishes it with nothing in between, so a
reader can theoretically see the pointer ahead of the zeroing and test an
uninitialised bit. Should we reallocate it in alloc_pseg(), or just add a
memory barrier?
|
