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

Re: [PATCH] IOMMU/x86: work around bogus gcc12 warning in hvm_gsi_eoi()


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 10 Jun 2022 09:29:44 +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=OFg+SRh2mEXaz+2IS2BU3ZXUtqSbZI+ynce61REkwpI=; b=O75O9EkNcSa89GGrsTunjUL2OB9jgXjjdAYjTRqEupBWvjo2Bn7yfmubHELVHmblOKOu3hwdDKheDLt6SfFxfDHVxKheOer9NgHdriUnMe8TsvFP3XGwq8RAF1v1emvgcveTzjnlSKKlD7gpF1/bVe54qo9tvz4NXOPd+t2YTt9oSsfvV9jVPJCOCZ798a7lft1Lda9ah3TAvJ8oRk8V+M0gg9o4HQtuqnO17yi50fdMcdZ7uiOGxTOyvIB03QcJqDtAKJlJjkXTihHmMqUli1l38cykfR9y7LGNbtoyPUtkW3v3FQyOE/pL61MVOdHNw4oWqBWvkpp5QW9blwo64A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iUnzLSENuXk3WIqnRZ1TXTwPbNe+gJnMmER4Yd3/0+rIBVVu4sQQ1st7d/7uDxHugDAmhaT2sUh3rr9iLma72ymQU7ZlHZRnrW7M3bHrJKNiXSvskpG/oJMNECTGs2jQPd053B7RomuF6LB8wdAAIO6Mu8N1YEEvefo8nERw2Ujb2p/lBzw7pJg4yK2R6lDTqbBXnu0Zx3boue+3x7ieJhpZ9NJJ1zE85jz88Z9OCWLRuc1Lx7IuchyRVcauwibbsUFKhFBgFrruGOk4CE4RIzwHGdBMyB/9sZuFbYv0a9OI/qXdMMR7FEO0xl+qcG5aXWcOIVDqLxuNTN+Tz8G5sQ==
  • 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>, Paul Durrant <paul@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Fri, 10 Jun 2022 07:29:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.06.2022 09:20, Roger Pau Monné wrote:
> On Fri, May 27, 2022 at 12:37:19PM +0200, Jan Beulich wrote:
>> As per [1] the expansion of the pirq_dpci() macro causes a -Waddress
>> controlled warning (enabled implicitly in our builds, if not by default)
>> tying the middle part of the involved conditional expression to the
>> surrounding boolean context. Work around this by introducing a local
>> inline function in the affected source file.
>>
>> Reported-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>
>> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967
>> ---
>> This is intended to replace an earlier patch by Andrew [2], open-coding
>> and then simplifying the macro in the one problematic place.
>>
>> Note that, with pirq_dpci() presently used solely in the one file being
>> changed here, we could in principle also remove the #define and use just
>> an inline(?) function in this file. But then the macro would need
>> reinstating as soon as a use elsewhere would become necessary.

Did you read this before ...

>> As to the inline - I think it's warranted here, but it goes against our
>> general policy of using inline only in header files. Hence I'd be okay
>> to drop it to avoid controversy.
>>
>> [2] https://lists.xen.org/archives/html/xen-devel/2021-10/msg01635.html
>>
>> --- a/xen/drivers/passthrough/x86/hvm.c
>> +++ b/xen/drivers/passthrough/x86/hvm.c
>> @@ -25,6 +25,18 @@
>>  #include <asm/hvm/support.h>
>>  #include <asm/io_apic.h>
>>  
>> +/*
>> + * Gcc12 takes issue with pirq_dpci() being used in boolean context (see gcc
>> + * bug 102967). While we can't replace the macro definition in the header 
>> by an
>> + * inline function, we can do so here.
>> + */
>> +static inline struct hvm_pirq_dpci *_pirq_dpci(struct pirq *pirq)
>> +{
>> +    return pirq_dpci(pirq);
>> +}
>> +#undef pirq_dpci
>> +#define pirq_dpci(pirq) _pirq_dpci(pirq)
> 
> That's fairly ugly.  Seeing as pirq_dpci is only used in hvm.c, would
> it make sense to just convert the macro to be a static inline in that
> file? (and remove pirq_dpci() from irq.h).

... saying so? IOW I'm not entirely opposed, but I'm a little afraid we might
be setting us up for later trouble. 

Jan



 


Rackspace

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