Re: [PATCH v3 5/7] vpci: add SR-IOV support for PVH Dom0

[Jan Beulich <jbeulich@xxxxxxxx>]

On 06.05.2026 11:39, Mykyta Poturai wrote:
> On 5/4/26 08:37, Jan Beulich wrote:
>> On 23.04.2026 12:12, Mykyta Poturai wrote:
>>> On 4/21/26 17:43, Jan Beulich wrote:
>>>> On 09.04.2026 16:01, 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. Also force VFs to
>>>>> always use emulated reads for command register, this is needed to
>>>>> prevent some drivers accidentally unmapping BARs.
>>>>
>>>> This apparently refers to the change to vpci_init_header(). Writes are
>>>> already intercepted. How would a read lead to accidental BAR unmap? Even
>>>> for writes I don't see how a VF driver could accidentally unmap BARs, as
>>>> the memory decode bit there is hardwired to 0.
>>>>
>>>>> Discovery of VFs is
>>>>> done by Dom0, which must register them with Xen.
>>>>
>>>> If we intercept control register writes, why would we still require
>>>> Dom0 to report the VFs that appear?
>>>>
>>>
>>> Sorry, I don't understand this question. You specifically requested this
>>> to be done this way in V2. Quoting your reply from V2 below.
>>>
>>>   > Aren't you effectively busy-waiting for these 100ms, by simply
>>> returning "true"
>>>   > from vpci_process_pending() until the time has passed? This imo is a
>>> no-go. You
>>>   > want to set a timer and put the vCPU to sleep, to wake it up again
>>> when the
>>>   > timer has expired. That'll then eliminate the need for the
>>> not-so-nice patch 4.
>>>
>>>   > Question is whether we need to actually go this far (right away). I
>>> expect you
>>>   > don't mean to hand PFs to DomU-s. As long as we keep them in the 
>>> hardware
>>>   > domain, can't we trust it to set things up correctly, just like we
>>> trust it in
>>>   > a number of other aspects?
>>
>> How's any of this related to the question I raised here, or your reply
>> thereto? If we intercept PCI_SRIOV_CTRL, we know when VFs are created.
>> Why still demand Dom0 to report them then?
>>
> 
> The spec states that VFs can take up to 100ms after the VF_ENABLE bit is 
> set to become alive. We discussed in the V2 that it is not acceptable to 
> do a required 100ms wait in Xen while blocking a domain. And not doing 
> that blocking would require some mechanism to only allow a domain to run 
> for precisely 99(or more?)ms. You yourself suggested that we can trust 
> the hardware domain with registering VFs if we already trust it with 
> other PCI-related stuff. Did you change your mind, or am I completely 
> misunderstanding this question?

No, I still think that we can trust hwdom enough. Nevertheless we should
aim at being independent of it where possible. And I seem to recall that
I had also outlined an approach how to avoid spin-waiting for 100ms in
the hypervisor.

Jan