Re: [PATCH v2 6/8] vpci: add SR-IOV support for PVH Dom0

[Mykyta Poturai <Mykyta_Poturai@xxxxxxxx>]

On 3/19/26 23:11, Stewart Hildebrand wrote:
> On 3/9/26 07:08, Mykyta Poturai wrote:
>> From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
>>
>> This code is expected to only be used by privileged domains,
>> unprivileged domains should not get access to the SR-IOV capability.
>>
>> Implement RW handlers for PCI_SRIOV_CTRL register to dynamically
>> map/unmap VF BARS. Recalculate BAR sizes before mapping VFs to account
>> for possible changes in the system page size register.
>>
>> Allow forcing vpci_modify_bars to not defer the actual mapping changes,
> 
> I don't think this is suitable. We perform the p2m operations in a deferred
> context because they may take a long time. And since they may take a long 
> time,
> the logic is interruptible: in map_range(), we perform a 
> general_preempt_check()
> and return -ERESTART so that we give a chance for other pending work to
> complete, including the scheduler softirq. If vpci_process_pending() returns
> true, it will be called again and is expected to resume where it left off. The
> vcpu won't continue until vpci_process_pending() returns false.
> 
>> which is needed to fix the sequential calls to vpci_modify_bars when
>> enabling VFs from Dom0.
> 
> I'm guessing you resorted to this because you need to perform multiple mapping
> operations, but the vPCI deferred mapping mechanism only supports a single
> operation? If so, this is an issue I've been attempting to resolve for some 
> time
> with the BAR-write-with-memory-decoding-enabled series [1]. In that series I'm
> working on introducing the ability perform multiple mapping operations. I'm
> almost ready to send v3 of the BAR-write-with-memory-decoding-enabled series,
> and I hope you don't mind that I include your patch ("vpci: Use pervcpu ranges
> for BAR mapping"). You may consider the possibility of basing SR-IOV on this
> work if suitable.
> 
> [1] 
> https://lore.kernel.org/xen-devel/20250723163744.13095-1-stewart.hildebrand@xxxxxxx/T/#t
> 

I’ve looked at your changes, but there seems to be a push against 
dynamically allocating tasks, which would not work with SR-IOV, or 
require a lot of task structs to be preallocated and used very rarely.

> Regardless, ultimately we need to find a way to return from
> vpci_process_pending() during the potentially long-running p2m operations.
> As an alternative suggestion, could you return from control_write_cb() after
> each call to map_vfs(), and somehow make it resume where it left off?

I’ll try this approach, thanks.

-- 
Mykyta