Re: [PATCH v3 4/7] vpci: allow queueing of mapping operations

[Stewart Hildebrand <stewart.hildebrand@xxxxxxx>]

On 4/22/26 07:38, Roger Pau Monné wrote:
> On Thu, Apr 09, 2026 at 02:01:33PM +0000, Mykyta Poturai wrote:
>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>> index b55bacbe6e..e34f7abe6d 100644
>> --- a/xen/include/xen/vpci.h
>> +++ b/xen/include/xen/vpci.h
>> @@ -155,14 +154,23 @@ struct vpci {
>>  };
>>  
>>  #ifdef __XEN__
>> -struct vpci_vcpu {
>> +struct vpci_map_task {
>>      /* Per-vcpu structure to store state while {un}mapping of PCI BARs. */
>> -    const struct pci_dev *pdev;
>> -    struct rangeset *mem[ARRAY_SIZE(((struct vpci_header *)NULL)->bars)];
>> +    struct list_head next;
>> +    struct vpci_bar_map {
>> +        uint64_t addr;
>> +        uint64_t guest_addr;
>> +        struct rangeset *mem;
>> +    } bars[ARRAY_SIZE(((struct vpci_header *)NULL)->bars)];
> 
> I'm a bit puzzled (possibly missing something), but why are you
> keeping this vpci_bar_map array here?  AFAICT map tasks are allocated
> on-demand after this change (by using {alloc,destroy}_map_task()).


Currently, a single mapping operation encompasses all BARs, so it's less
overhead. This is tied to the way modify_bars() populates and queues a mapping
operation: it iterates over the BARs multiple times before queuing it up. I
could see a point in perhaps allocating a map task per BAR. Indeed, in the next
rev of the BAR-write-with-memory-decoding patch, I'm planning to introduce the
ability to map/unmap a single BAR. If we allocate a map task per BAR, however,
we'd have additional overhead with tracking 'const struct pci_dev *pdev' and
'bool map' per BAR instead of per PCI device, along with refactoring of
modify_bars(). Since mapping only a single BAR is still a rather uncommon corner
case, my first thought is that it's not necessarily worth it to make struct
map_task only hold information for a single BAR. You can see a preview of the
next rev of the BAR-write-with-memory-decoding patch at [1] since I haven't yet
sent it out.

[1] 
https://gitlab.com/xen-project/people/stewarthildebrand/xen/-/commit/d20f252670dff2d01c4c0c4b815abb2cae07062e