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

Re: [PATCH V7 09/11] vpci: add initial support for virtual PCI bus topology


  • To: Oleksandr <olekstysh@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 28 Jul 2022 16:26:45 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LfRGgEhkGeIOHRJqxjbjIEei+ZFgwTgGMNrwXM3A7Q0=; b=lMYqO/5P7VPdqv5EdT3T+5GlAQtwHJXxtOhwWpqlWlSJ86k0ZiT+VlCCAUi/rFxDGY5Pg7Yk+F+1e5kvWmb9KQdPOiF8OJT0+Kv65Kjde1qg2s+jHV+hUpEZgqk8Y6ewjOnJXqeF2vlR6GlhP2ozPc0YEisTRlzT69R0fO0MH1aeNBvFN/q90RTsExUTTBDgOq0ob89YvujZGU97hvkX1lZBRd3qhcGo2GEOTqgebqOADQaZRM93ob8vDozYmeiqkgBMGaKqtX/LRLTL/obB75Ff7RxXrpzGKsXaxaKHGtonGziasxa8f54NqyjGA+F5WmhCMMPCsNuKBcOQU9hQ7A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B1EWFd9m1gBboBXZBXCOSBh7VlQz6xlhFJJ1avUfrBAtrhfWjSwpoGEG706YhPLwkIKZQSpg6Qrd30PQugWQxSD/nvRDF1bivlH6V9i9aaJ83QHOkBagMsxiRg6jQ2YYZ6rOVhQpYmKqlH/6VkL9+JEv7bW8QD0ZFP+jo3nNOHbNbkQhD00MmthCytDHjSxg4+95Ni3WNrST+jxmtSqBdiyq/vdhJu9ZkuraYVFvljMpkChj0iJtILimGByxkSHt/IPonRXhHVNnDyKoWPqbz1WGTBbslOUGYmDAwdzj4XLVMHrqexfhygjoxa7NeesrS9pCd2xUsu1Bc4pdgEc3zQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 28 Jul 2022 14:26:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 28.07.2022 16:16, Oleksandr wrote:
> On 27.07.22 13:32, Jan Beulich wrote:
>> On 19.07.2022 19:42, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>
>>>
>>> Assign SBDF to the PCI devices being passed through with bus 0.
>>> The resulting topology is where PCIe devices reside on the bus 0 of the
>>> root complex itself (embedded endpoints).
>>> This implementation is limited to 32 devices which are allowed on
>>> a single PCI bus.
>>>
>>> Please note, that at the moment only function 0 of a multifunction
>>> device can be passed through.
>> I've not been able to spot where this restriction is being enforced -
>> can you please point me at the respective code?
> 
> Nor have I found the respective code.
> 
> Could you please suggest a place where to put such enforcement (I guess, 
> this should be present in the toolstack)?

Such check should be in the tool stack primarily to give a sensible
error message to the user. Yet the hypervisor needs to check itself
nevertheless. You know the code you're adding much better than I do,
so I guess I'm a little puzzled by you asking me to suggest a place.
(And for the tool stack I guess asking tool stack folks would get
you better mileage.)

>>> @@ -124,6 +191,7 @@ void vpci_deassign_device(struct pci_dev *pdev)
>>>       if ( !has_vpci(pdev->domain) )
>>>           return;
>>>   
>>> +    vpci_remove_virtual_device(pdev);
>>>       vpci_remove_device(pdev);
>>>   }
>> And other call sites of vpci_remove_device() do not have a need of
>> cleaning up guest_sbdf / vpci_dev_assigned_map?
> 
> I am not 100% sure, but it looks like they don't need. On the other 
> hand, even if they don't need that, doing the cleaning won't be an issue 
> at all,
> 
> there is a check before cleaning (which will be extended as I proposed 
> above), so ...
> 
> 
>> IOW I wonder if it
>> wouldn't be better to have vpci_remove_device() do this as well
>> (retaining - see my comment on the earlier patch) the simple aliasing
>> of vpci_deassign_device() to vpci_remove_device()).
> 
> 
>     ... maybe yes. Shall I do that change?

Well - yes please, afaic.

Jan



 


Rackspace

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