[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 2/4] vpci: allow queueing of mapping operations
- To: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Mykyta Poturai <Mykyta_Poturai@xxxxxxxx>
- Date: Thu, 9 Apr 2026 15:17:30 +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=+bTtnVqI/njnm9mF5eUmSq8syIognAlgqXXNHsvjoUM=; b=M0GgTAJrlVyb2XeUvLbE9grmmvGOe0TGtmTFLYrNVJykfLHMTeN3CuNtRsP1EpXfanI4ucloJiHDBNGInuf5eZIPgfuMgDUEbUtZotyjgUE1svHShUSPH1JWM5kohMfebSZk1s5SRqf2tGJ98aOEeaRhNdTnSvd1/pBGg/a1l0dPrnrPvhFEkU2lCYxNawabdnfqZ5DclTMAXqTVguZCkqj8oL8dj1FaSMrl3pjWOD4vAs31r0g31xx3hxGOOzKANZ4pHFVM2p3I+ZA/21eiT8lX5jdQ1Cleap5TGej0zromh5SSaq6FonNZ76BAeoBEj+NFIp20FQmgoP3JyUqRlw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jEsavm0vu2GhdhCk4Vx2JGALQlAuHnSej8P9K0sYsFrMOVdczovQo1mNXbQQEyfRHW1heq5nYgc412Fo9wg50kKQHkhQ96c1/5vwPFHzbrtEgA3pvzPG5wUtEWipISiiW4Rls23hZkA6K93wXBU8qIx+mGC59pxo0jdVD7tDNKv//aLB1Dm/TgutdwI5e0Z3Z4OaH58S8CHkP5IMC8I18HMXFQ+i7/jsDWkCE8GicD6U/Z3tp9TxJ2pZiZCgcjU//g/02YZ1v/W4OTPZp9xL3IY4im4dH+jjOctoVHZfbfb5Efv0aGn2axyzOZCi+oElqhwW6WyGJxCSwBPTsM8gXA==
- 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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
- Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
- Delivery-date: Thu, 09 Apr 2026 15:17:36 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Thread-index: AQHcxflWTbgzk4jzUUShSlP6L/DRmLXW3AQA
- Thread-topic: [PATCH v4 2/4] vpci: allow queueing of mapping operations
On 4/6/26 22:11, Stewart Hildebrand wrote:
> Introduce vPCI BAR mapping task queue. Store information needed to
> map/unmap BARs in struct vpci_map_task. Allow queueing of BAR map/unmap
> operations in a list, thus making it possible to perform multiple p2m
> operations associated with single PCI device.
>
> This is preparatory work for further changes that need to perform
> multiple unmap/map operations before returning to guest.
>
> At the moment, only a single operation will be queued. However, when
> multiple operations are queued, there is a check in modify_bars() to
> skip BARs already in the requested state that will no longer be
> accurate. Remove this check in preparation of upcoming changes.
>
> Signed-off-by: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
> ---
> apply_map() and vpci_process_map_task() are very similar. Should we try
> to combine them into a single function?
>
> I concede that the dynamic allocation/deallocation of struct
> vpci_map_task is not ideal. However, to support SR-IOV, there will be a
> need to queue many mapping operations (one per VF), and statically
> pre-allocating that much would seem wasteful. Only the hardware and/or
> control domain would need to queue many operations, and only when
> configuring SR-IOV.
>
> v3->v4:
> * switch back to dynamically allocated queue elements
>
> v2->v3:
> * base on ("vpci: Use pervcpu ranges for BAR mapping") from [1]
> * rework with fixed array of map/unmap slots
>
> [1]
> https://lore.kernel.org/xen-devel/cover.1772806036.git.mykyta_poturai@xxxxxxxx/T/#t
>
> v1->v2:
> * new patch
It seems like this patch is modifying a lot of the same code as the
previous one. Maybe it will be a good idea to squash them into a single one?
--
Mykyta
|
