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

[Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>]

Hi Jan,

Jan Beulich <jbeulich@xxxxxxxx> writes:

> On 07.05.2026 22:40, Volodymyr Babchuk wrote:
>> Jan Beulich <jbeulich@xxxxxxxx> writes:
>>> 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.
>> 
>> I want to clarify: you are telling that Xen should not wait for hwdom to
>> report VFs and instead create them by itself. Is this correct?
>
> If that's technically possible, yes.

Okay, so let's clear this. If I remember correct, you discussed this
with Mykyta in the previous version and suggested to put the vCPU to
sleep for 100ms. I don't think that this is a good idea, because guest
kernel will not be happy about that. So, IMO, it is better to just
allows the guest to tell Xen when VFs are ready.

Or maybe I am missing something and you had some another idea?

-- 
WBR, Volodymyr