Re: SR-IOV: do we need to virtualize in Xen or rely on Dom0?

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

On 10.06.21 15:02, Jan Beulich wrote:
> On 10.06.2021 13:45, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 10.06.21 13:48, Jan Beulich wrote:
>>> On 10.06.2021 12:01, Oleksandr Andrushchenko wrote:
>>>> On 10.06.21 10:54, Roger Pau Monné wrote:
>>>>> OTOH if we properly trap accesses to the SR-IOV capability (like it
>>>>> was proposed in [1] from your references) we won't have to modify OSes
>>>>> that want to run as hardware domains in order to handle SR-IOV devices.
>>>> Out of curiosity, could you please name a few? I do understand that
>>>>
>>>> we do want to support unmodified OSes and this is indeed important.
>>>>
>>>> But, still what are the other OSes which do support Xen + PCI passthrough?
>>> I think Roger saying "want" meant to cover ones which currently don't,
>>> and which would have to undergo more extensive changes if they were to
>>> be enabled.
>> Fair enough. Do you think we would also need to re-work the existing code
>>
>> in Xen to support normal devices (not SR-IOV), e.g. we currently rely on
>>
>> PHYSDEVOP_XXX and other Linux specifics.
> Yes, work in that area would also be needed. For example we'd need to
> scan buses / segments as they become accessible. Right now we only scan
> segment 0, and even that's only possible because on x86 mmconfig is not
> the only way to access config space.
>
>> And even if SR-IOV is implemented
>>
>> in Xen this won't allow those OSes to stay unmodified, including FreeBSD.
> Of course, it's the nature of PVH (as opposed to HVM) that OSes need
> modification. The question is the scope thereof.

Ok, then it seems I need to get [1] back into the picture.

I have modified vPCI code a lot for ARM support, so [1] will not apply

as is anymore and needs to be re-worked. But, still it can mostly be re-used


> Jan
>
Thank you,

Oleksandr

[1] https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg01494.html