Re: [RFC PATCH 2/6] xen/public: arch-arm: reserve resources for virtio-pci

[Julien Grall <julien@xxxxxxx>]

Hi Volodymyr,

On 16/11/2023 16:53, Volodymyr Babchuk wrote:
> Julien Grall <julien@xxxxxxx> writes:
> > On 16/11/2023 15:26, Stewart Hildebrand wrote:
> > > On 11/16/23 10:12, Julien Grall wrote:
> > > > Hi Volodymyr,
> > > >
> > > > On 16/11/2023 15:07, Volodymyr Babchuk wrote:
> > > > > With my vPCI patch series in place, hypervisor itself assigns BDFs for
> > > > > passed-through devices. Toolstack needs to get this information to know
> > > > > which BDFs are free and can be used by virtio-pci.
> > > > It sounds a bit odd to let the hypervisor to assign the BDFs. At
> > > > least because there might be case where you want to specific vBDF
> > > > (for instance this is the case with some intel graphic cards). This
> > > > should be the toolstack job to say "I want to assign the pBDF to
> > > > this vBDF".
> > > Keep in mind we are also supporting dom0less PCI passthrough.
> > Right, but even with that in mind, I expect the Device-Tree to provide
> > the details where a given PCI is assigned.
> >
> > You could have logic for assigning the BDF automagically. But that
> > should be part of dom0less, not deep into the vPCI code.
> As far as I know, right now toolstack does not allow you to assign BDF
> in any form. For x86 there are two options, and they are controlled by
> "passthrough" option of xen-pciback driver in Linux:
Are you talking about HVM or PV? I am not very familiar for the latter 
but for the former, QEMU is today responsible to find a free slot.
You can also specify which virtual slot you want to use in XL:

=item B<vslot>=I<NUMBER>

=over 4

=item Description

Specifies the virtual slot (device) number where the guest will see this
device. For example, running L<lspci(1)> in a Linux guest where B<vslot>
was specified as C<8> would identify the device as C<00:08.0>. Virtual 
domain
and bus numbers are always 0.

>    "Option to specify how to export PCI topology to guest:"
>    " 0 - (default) Hide the true PCI topology and makes the frontend"
>    "   there is a single PCI bus with only the exported devices on it."
>    "   For example, a device at 03:05.0 will be re-assigned to 00:00.0"
>    "   while second device at 02:1a.1 will be re-assigned to 00:01.1."
>    " 1 - Passthrough provides a real view of the PCI topology to the"
>    "   frontend (for example, a device at 06:01.b will still appear at"
>    "   06:01.b to the frontend). This is similar to how Xen 2.0.x"
>    "   exposed PCI devices to its driver domains. This may be required"
>    "   for drivers which depend on finding their hardward in certain"
>    "   bus/slot locations.");
>
> Also, isn't strict dependency on BDF breaks the PCI specification? I
> mean, of course, you can assign Function on random, but what about Bus
> and Device parts?
I am not well-versed with the PCI specification. However, what the specs 
says and what users do tend to be different :).
I know a few cases where you need to specify the slot. I have mentioned 
one earlier with the Intel Graphic cards.
> I mean, we can make toolstack responsible of assigning BDFs, but this
> might break existing x86 setups...
It is not clear to me how letting the toolstack selecting the vslot 
would be a problem for HVM (see above). However, it is clear that you 
may break some x86 setup if always allocate a "random" slot.
Cheers,

--
Julien Grall