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

Re: [PATCH] PCI: avoid bogus calls to get_pseg()


  • To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>, Rahul Singh <Rahul.Singh@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 11 Aug 2022 09:02:26 +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=8UntFayVAp+lMaQMMIqc5Pf7A1gF6CGWwYw7mxljBI4=; b=Z9WeMphZaHQyf8LWRdR0NfFOwSpWYds4sGXoFpM3TNsVIorOKEExhEDfuICiOQQ+VvKvdHBhvf3t2AtlZb6SzRX08JWardx0Jq2TKe7lGyxwr3vR226QYxK6h5CAY3X7bSYqswl6LQFX4aDoFmBXCOCh/rufkspgXObQFbaFj60/6wRyKes5T8LsgFLE3sshy9C6mXNBrJqv78HzKFRxiz5y3c3Jex/vYqidwd0j64QvODMuqVGa89LCnqcPXt04nIF1jejyTUGFTBYIIAefIGKi8gISjMq0qkQpg3n8jcddIREGoFA46GUB7NlsM48D19xO1MfZgo6jrMYQZ9ra2Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JeOvEsYj6T647nwigO04pE+PhtIlb9MFFSELgMDxCRNP1s0yyxFEI5BRuZrWpLbrw6r2EXqFhbDoHxFC3cj8ryKwwLsd/Z+kAE7bkydj160yLvTziruhCAI2hEAN2MGHTHftwEuvnTWQyrVuAMsjb6uyZDceiftqt8y7DM6dFMD0FNxz+djk5TWZ632MBNOT8pvK/FMelNMjafIr35Nf50ax9vttiDNe8QQY280Yw2rXieBB7c+7IRw1PcVFYnYOL+RrsAKd4cSd+tBSiSFk2ADSQPGhii8v1JV9UnGwvKaU9urrTup5nOPboKmPXOYseZFx3DF67IM6k+i2Sj4gQw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 11 Aug 2022 07:02:49 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.08.2022 14:13, Andrew Cooper wrote:
> On 09/08/2022 16:50, Jan Beulich wrote:
>> When passed -1, the function (taking a u16) will look for segment
>> 0xffff, which might exist. If it exists, we may find (return) the wrong
>> device.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> An alternative would be to declare that both functions cannot be called
>> with "wildcards" anymore. The last such use went away with f591755823a7
>> ("IOMMU/PCI: don't let domain cleanup continue when device de-assignment
>> failed") afaict.
> 
> The way wildcards were used before were always bogus IMO.
> 
> I suggest we take this opportunity to remove the ability to re-introduce
> that anti-pattern.

Okay, will do that in v2. Rahul - this means there's no point anymore
sending a v2 of your fix, as the bug will disappear as a side effect.
I'll add you as the reporter of that bug.

>> Each time I look at this pair of functions I wonder why we have two
>> copies of almost the same code (with a curious difference of only one
>> having ASSERT(pcidevs_locked())). Any opinions on deleting either one,
>> subsuming its functionality into the other one by allowing the domain
>> pointer to be NULL to signify "any"?
> 
> I'm in two minds about this.  Because they are the same, they ought to
> be deduped.
> 
> Except they're both insane and both want changing to a less silly
> datastructure, at which point they will be different.
> 
> It is a total waste to do an O(n) loop over all PCI devices in the
> system checking for equality to single device (and in the domain case,
> assignment to the domain).  The domain variant should loop over the pci
> devices in that domain, because it is guaranteed to be a shorter list
> than all devices.

With the "wildcard" support gone, that's going to be sensible, yes,
and I'll switch to that. Except for hwdom, where I mean to stick to
the per-segment all-devices lists, as on multi-segment systems these
are very likely the shorter lists, while on single-segment systems
the sole all-devices list likely isn't much longer than the list of
hwdom's devices (the delta being all devices [intended to be] passed
through plus all hidden devices). At this point I'm not sure whether
it would be worth further special-casing the single-segment case,
even if that's (on x86) the applicable one on the vast majority of
systems.

> The global lookup probably wants to investigate a more efficient
> datastructure because I bet this is a hotpath.

I don't think it's a hot path, but it can certainly be improved. Yet
that's future work, nothing to be done right here. But I'm inferring
you agree in this regard by saying "investigate".

Jan



 


Rackspace

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