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

Re: [PATCH] x86/passthrough: Fix hvm_gsi_eoi() build with GCC 12


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 2 Nov 2021 13:39:22 +0100
  • 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=eG5RqtAInVJ4hHUOj/Qg/9qsC+6jqjTP3TBobnHtkHA=; b=bA7Bt9KuFgfzTqLeq/H4xc9oq/oRxWFltR2pyCmPUASOtYvJ2Vue7Bwvb0TZV4a0K3UNCRWiQqTfE4qa9Qpdg6C4Mn5oodl7Za21HsN0tyCw8uQAX/g5mH8cJKDMBfNZTulOPPAHAOuEWSCyD14p8apKOtk7IHqQXD/4gwYJ3bzwkxaHlN7n8M+5xQYtuWfSVrcVvt9djGc0XIybhMB+Hszd/x+LjhiImm37cfylDACLZCw+LmKE4d/hUmYnGaAY3phuB5DNQY2116ozx6c6RtL0s8jrbgQlC1HUosuRX1zvMZDmJaoZlMtV1YdZ9QDkffCNhNq9Uw3W/AJ+6ukfjg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RhKwoar0xwTqCvLNQ7NnHc+gQTtCLWN/iEhQTHnr/XPbLhKqferyG562WvpzsK00Vj/N/PWrktSSROzKufaJXo+D2DjO8a365g/Ix50t7rMtTTm/EBl0q0gJtyRgAyknlMt8GhxWm43Rffcy+lNAucWVazWyZc32AieV2gSXEH8sAN/rJirCP5pfwBot9DlSgom9BIPm6fKI7u5XDViKEFuqbIsMiQfCpWSOOEIuyahP4RgAYuUxb4ZJutqjLdvlEblSl9xoxaKUPQ2m0J8prZ1Jsouebf7755CSaDlkkOFa0Jgpd5frbHGFwR5KrGOwW19ueceLJ9qkMAGhxwGtzQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 02 Nov 2021 12:39:44 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.10.2021 22:07, Andrew Cooper wrote:
> GCC master (nearly version 12) complains:
> 
>   hvm.c: In function 'hvm_gsi_eoi':
>   hvm.c:905:10: error: the comparison will always evaluate as 'true' for the
>   address of 'dpci' will never be NULL [-Werror=address]
>     905 |     if ( !pirq_dpci(pirq) )
>         |          ^
>   In file included from /local/xen.git/xen/include/xen/irq.h:73,
>                    from /local/xen.git/xen/include/xen/pci.h:13,
>                    from /local/xen.git/xen/include/asm/hvm/io.h:22,
>                    from /local/xen.git/xen/include/asm/hvm/domain.h:27,
>                    from /local/xen.git/xen/include/asm/domain.h:7,
>                    from /local/xen.git/xen/include/xen/domain.h:8,
>                    from /local/xen.git/xen/include/xen/sched.h:11,
>                    from /local/xen.git/xen/include/xen/event.h:12,
>                    from hvm.c:20:
>   /local/xen.git/xen/include/asm/irq.h:140:34: note: 'dpci' declared here
>     140 |             struct hvm_pirq_dpci dpci;
>         |                                  ^~~~
> 
> The location marker is unhelpfully positioned and upstream may get around to
> fixing it.  The complaint is intended to be:
> 
>   if ( !((pirq) ? &(pirq)->arch.hvm.dpci : NULL) )

I disagree with the compiler's analysis: While &(pirq)->arch.hvm.dpci
indeed can't be NULL, that's not the operand of !. The operand of !
can very well be NULL, when pirq is.

> which is a hint that the code is should be simplified to just:
> 
>   if ( !pirq )
> 
> Do so.

And I further agree with Roger's original reply (despite you
apparently having managed to convince him): You shouldn't be open-
coding pirq_dpci(). Your observation that the construct's result
isn't otherwise used in the function is only one half of it. The
other half is that hvm_pirq_eoi() gets called from here, and that
one does require the result to be non-NULL.

Jan




 


Rackspace

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