[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Mon, 7 Dec 2020 09:37:29 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lTLcE0GIJgeLOO7/j6fHvOiyBigzz/3CQWCEoJOdosw=; b=jSb0RwsvYo8ARbnsKzmuZPoWuOzjYeNDrrWQcPPHSjEsbbZC6Qk4XM5SKSTA1oY/HpOZ8hs5Cr7jvbwxM8yvxj7OTqp25yTZ207BVvdkk5DwyNkADQBFVq2gtXU7xhy+EG+Q6F8EOT/Pcw9XzFDzp2NhaajPUqTDh+6MdQrOohIS7g0/kAAu/8KYt1YP4hfOWTKsjaRfs6Woo9XGhGoLtXeq+ViXK744jCwfxzl0BQ7Gqt5jhzQ1/TMi+PlY9S+YxGQ45phs/LL1OvELO+4T886sfI7WYj4t+yrd58kL801XaEKfRliPOPyM3U/N83az3eHW4t1qG+EbwvOAapEjHw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UN38E0pZUJB/PFsHt/oCnfnjh8lfjWFR6xMNHgA2CK63qFtiUSG4ezzxz+6ngm9k/FC8BwnU5FwEAqbpKIA1CqwDMp2eLf7eiAq+SMqpddmYzinfQptU54aftzyZwLrqRp3AKlDSSj8nhQFeWOQS1CFaxBEAXn/kWlTk+oBCIvM/8QitWZTa91jfFvxlx5x+NmzciHSkLOVNFAMOj9UN8884YDfJ2ZNY/cRatm3VzgmuXrHMYk9D5SUx7D+uAZ/Tyh65NfYHG5+ob3oi3yTRWYxyXTXlh+vBUftCOtaDMA/A6sPD5kU28nsjzlvpX7tWkHOUq8xeGUxF6+P5hwT1HQ==
  • Authentication-results: suse.com; dkim=none (message not signed) header.d=none;suse.com; dmarc=none action=none header.from=epam.com;
  • Cc: Oleksandr Andrushchenko <andr2000@xxxxxxxxx>, "Rahul.Singh@xxxxxxx" <Rahul.Singh@xxxxxxx>, "Bertrand.Marquis@xxxxxxx" <Bertrand.Marquis@xxxxxxx>, "julien.grall@xxxxxxx" <julien.grall@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "iwj@xxxxxxxxxxxxxx" <iwj@xxxxxxxxxxxxxx>, "wl@xxxxxxx" <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 07 Dec 2020 09:37:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWtpbzyJg77SbpvkSRWLKjWy/3PanEQmgAgAA8YoCAABlOgIABCD8AgABBOQCAAAXIAIAAAS0AgAADNgCAAAlOAIAAEnYAgAAcfoCAAAKRAIAAAYQAgAABxICAAAHUgIAg/YsAgARU+oCAAAZpgIAABNqAgAAChwA=
  • Thread-topic: [PATCH 06/10] vpci: Make every domain handle its own BARs

On 12/7/20 11:28 AM, Jan Beulich wrote:
> On 07.12.2020 10:11, Oleksandr Andrushchenko wrote:
>> On 12/7/20 10:48 AM, Jan Beulich wrote:
>>> 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.
>> So, for example:
>>
>> commit 0af438757d455f8eb6b5a6ae9a990ae245f230fd
>> Author: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
>> Date:   Fri Sep 27 10:11:49 2013 +0200
>>
>>       AMD IOMMU: fix Dom0 device setup failure for host bridges
>>
>>       The host bridge device (i.e. 0x18 for AMD) does not require IOMMU, and
>>       therefore is not included in the IVRS. The current logic tries to map
>>       all PCI devices to an IOMMU. In this case, "xl dmesg" shows the
>>       following message on AMD sytem.
>>
>>       (XEN) setup 0000:00:18.0 for d0 failed (-19)
>>       (XEN) setup 0000:00:18.1 for d0 failed (-19)
>>       (XEN) setup 0000:00:18.2 for d0 failed (-19)
>>       (XEN) setup 0000:00:18.3 for d0 failed (-19)
>>       (XEN) setup 0000:00:18.4 for d0 failed (-19)
>>       (XEN) setup 0000:00:18.5 for d0 failed (-19)
>>
>>       This patch adds a new device type (i.e. DEV_TYPE_PCI_HOST_BRIDGE) which
>>       corresponds to PCI class code 0x06 and sub-class 0x00. Then, it uses
>>       this new type to filter when trying to map device to IOMMU.
>>
>> One of my test systems has DEV_TYPE_PCI_HOST_BRIDGE, so bus2brdige setup is 
>> ignored
> If there's data to be sensibly recorded for host bridges, I don't
> see why the function couldn't be updated. I don't view this as
> x86-specific; it may just be that on x86 we have no present use
> for such data. It may in turn be the case that then x86-specific
> call sites consuming this data need updating to not be mislead by
> the change in what data gets recorded. But that's still all within
> the scope of bringing intended-to-be-arch-independent code closer
> to actually being arch-independent.

Well, the patch itself made me think that this is a workaround for x86

which made DEV_TYPE_PCI_HOST_BRIDGE a special case and it relies on that.

So, please correct me if I'm wrong here, but in order to make it really generic

I would need to introduce some specific knowledge for x86 about such a device

and make the IOMMU code rely on that instead of bus2bridge.

>
> Jan

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.