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

[Stewart Hildebrand <stewart.hildebrand@xxxxxxx>]

On 4/2/26 11:52, Mykyta Poturai wrote:
> On 3/24/26 05:04, Stewart Hildebrand wrote:
>> Introduce vPCI BAR mapping task queue. Store information necessary in an
>> array in struct vpci_vcpu to perform multiple p2m operations associated
>> with single 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 slot is needed in the array. However, when
>> multiple operations are queued and pending, there is a check in
>> modify_bars() to skip BARs already in the requested state that is not
>> accurate. Remove this check.
>>
>> 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?
>>
>> 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
> 
> Hi everyone,
> 
> 
> Would it be possible to move back to a dynamically allocated number of 
> tasks? This would help with mapping SR-IOV virtual functions a lot. 
> @Stewart @Roger, what are your thoughts?

Yes, assuming each VF will need another queued map operation, and there could be
a lot of VFs, statically pre-allocating that much seems wasteful. Only the
control and/or hardware domains will queue a lot of operations, and only when
enabling SR-IOV. DomUs will only queue 1 operation (possibly 2 if we will allow
domU BAR writes with memory decoding enabled).

So I'll plan to switch back to dynamically allocated map tasks for v4.

> Alternatively, I can continue with an approach described in SR-IOV 
> series, where VFs are handled separately. I figured out how to return to 
> do_softirq after mapping each VF, so it should not block the CPU for too 
> long.
>