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

Re: [PATCH v3 2/6] xen: pci: introduce reference counting for pdev


  • To: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 21 Apr 2023 14:24:25 +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=qc5xUyGW06UDfQIBCdqwAH+qHYdibFuKOlXfBc/eo4M=; b=QS8Ec9osC7sKxrAv+sIUjvIwtcQHCxGDtvyKgETbHt5vBZpdMRd4+C0zx9McxZWQc/4qSaKQrRn6vRIDodNz8CInC2qfmwPTOMFkxkdS61xgkpPVNlEfZpPPz9/FgZ6guhnWQniqgNyMweekqnu02BW+7qzQVDIPhmJV/6YL+RlB0Q9gIUZ95+EAWUkmt+Z8/gsx6OazV1ZbvVm/m2NjUYi9R3kcBz/bOzg8vdApJQZKQHCjIf3oBD5FpxVDeFcuEoWOAtW+lXXzaohZiErknVOLTXVUDXvRxP6rAp6mlgKTM8VbjslpyZjt+Z5U4ZASKx1lw8A1rAH70Tx2LZLNTw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K1SPoFGn2WeK0Cz7oLBj/6kaB62Hm6Fxg8m4RCzgyiozrK2ytanqbFQvKiSuktCsyiZ6EExSqcEnYefjxGGJ+at5p07O44EQ9TCmX5yrfn/F8oYJaDffPU/dtBkzTESwbdJRvDnfvN1E0BQQKS90+aw3u6luiin48ETa3VoiSsY5VoRG4mYsMWEohH85f1XR/BX/zwwrnM2VApuRQJHv57Tp5kd+RuZDcM+Q/eiKJruF3vVFCncixs/53xZjty7yvfvUsT+wGFWzhOL0fseOC/k9cS59VSfjYeirumVm1jdiSb/SMqeRMjERSfXq0CvPZS5WsZFvbTNYCJvJrXlhWg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Fri, 21 Apr 2023 12:24:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 21.04.2023 13:00, Volodymyr Babchuk wrote:
> 
> Hello Roger,
> 
> Roger Pau Monné <roger.pau@xxxxxxxxxx> writes:
> 
>> On Mon, Apr 17, 2023 at 12:34:31PM +0200, Jan Beulich wrote:
>>> On 17.04.2023 12:17, Roger Pau Monné wrote:
>>>> On Fri, Apr 14, 2023 at 01:30:39AM +0000, Volodymyr Babchuk wrote:
>>>>> Above I have proposed another view on this. I hope, it will work for
>>>>> you. Just to reiterate, idea is to allow "harmless" refcounts to be left
>>>>> after returning from pci_remove_device(). By "harmless" I mean that
>>>>> owners of those refcounts will not try to access the physical PCI
>>>>> device if pci_remove_device() is already finished.
>>>>
>>>> I'm not strictly a maintainer of this piece code, albeit I have an
>>>> opinion.  I will like to also hear Jans opinion, since he is the
>>>> maintainer.
>>>
>>> I'm afraid I can't really appreciate the term "harmless refcounts". Whoever
>>> holds a ref is entitled to access the device. As stated before, I see only
>>> two ways of getting things consistent: Either pci_remove_device() is
>>> invoked upon dropping of the last ref,
>>
>> With this approach, what would be the implementation of
>> PHYSDEVOP_manage_pci_remove?  Would it just check whether the pdev
>> exist and either return 0 or -EBUSY?
>>
> 
> Okay, I am preparing patches with the behavior you proposed. To test it,
> I artificially set refcount to 2 and indeed PHYSDEVOP_manage_pci_remove
> returned -EBUSY, which propagated to the linux driver. Problem is that
> Linux driver can't do anything with this. It just displayed an error
> message and removed device anyways. This is because Linux sends
> PHYSDEVOP_manage_pci_remove in device_remove() call path and there is no
> way to prevent the device removal. So, admin is not capable to try this
> again.

So maybe Linux'es issuing of the call needs moving elsewhere? Or we need
a new sub-op, such that PHYSDEVOP_manage_pci_remove can remain purely a
last-moment notification?

> As I workaround, I can create hypercall continuation in case if
> pci_remove_device() returns -EBUSY. What is your opinion?

How would that help? You'd then spin perhaps for hours or days ...

Jan



 


Rackspace

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