Re: [PATCH 06/10] vpci: Make every domain handle its own BARs

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.12.2020 15:38, Oleksandr Andrushchenko wrote:
> On 11/13/20 4:51 PM, Jan Beulich wrote:
>> On 13.11.2020 15:44, Oleksandr Andrushchenko wrote:
>>> On 11/13/20 4:38 PM, Jan Beulich wrote:
>>>> On 13.11.2020 15:32, Oleksandr Andrushchenko wrote:
>>>>> On 11/13/20 4:23 PM, Jan Beulich wrote:
>>>>>>     Earlier on I didn't say you should get this to work, only
>>>>>> that I think the general logic around what you add shouldn't make
>>>>>> things more arch specific than they really should be. That said,
>>>>>> something similar to the above should still be doable on x86,
>>>>>> utilizing struct pci_seg's bus2bridge[]. There ought to be
>>>>>> DEV_TYPE_PCI_HOST_BRIDGE entries there, albeit a number of them
>>>>>> (provided by the CPUs themselves rather than the chipset) aren't
>>>>>> really host bridges for the purposes you're after.
>>>>> You mean I can still use DEV_TYPE_PCI_HOST_BRIDGE as a marker
>>>>>
>>>>> while trying to detect what I need?
>>>> I'm afraid I don't understand what marker you're thinking about
>>>> here.
>>> I mean that when I go over bus2bridge entries, should I only work with
>>>
>>> those who have DEV_TYPE_PCI_HOST_BRIDGE?
>> Well, if you're after host bridges - yes.
>>
>> Jan
> 
> So, I started looking at the bus2bridge and if it can be used for both x86 
> (and possible ARM) and I have an
> 
> impression that the original purpose of this was to identify the devices 
> which x86 IOMMU should
> 
> cover: e.g. I am looking at the find_upstream_bridge users and they are x86 
> IOMMU and VGA driver.
> 
> I tried to play with this on ARM, and for the HW platform I have and QEMU I 
> got 0 entries in bus2bridge...
> 
> This is because of how xen/drivers/passthrough/pci.c:alloc_pdev is 
> implemented (which lives in the
> 
> common code BTW, but seems to be x86 specific): so, it skips setting up 
> bus2bridge entries for the bridges I have.

I'm curious to learn what's x86-specific here. I also can't deduce
why bus2bridge setup would be skipped.

> These are DEV_TYPE_PCIe_BRIDGE and DEV_TYPE_PCI_HOST_BRIDGE. So, the 
> assumption I've made before
> 
> that I can go over bus2bridge and filter out the "owner" or parent bridge for 
> a given seg:bus doesn't
> 
> seem to be possible now.
> 
> Even if I find the parent bridge with 
> xen/drivers/passthrough/pci.c:find_upstream_bridge I am not sure
> 
> I can get any further in detecting which x86 domain owns this bridge: the 
> whole idea in the x86 code is
> 
> that Domain-0 is the only possible one here (you mentioned that).

Right - your attempt to find the owner should _right now_ result in
getting back Dom0, on x86. But there shouldn't be any such assumption
in the new consumer of this data that you mean to introduce. I.e. I
only did suggest this to avoid ...

> So, I doubt if we can still live with
> 
> is_hardware_domain for now for x86?

... hard-coding information which can be properly established /
retrieved.

Jan