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

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


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 18 Nov 2021 10:50:40 +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=yKJFd/BdYdio66y0jSOGBawJmr1iTWg0b1pZ60kB3eo=; b=e0XFj2ESi2PdIyE4uR9t3kxFx6bMs77GCfyZc4AZ0CGJFV7njYFd9YRGbsSBnXtipqwM7ZeQFlHVGeOQAtMQHKhc5G9L2DbezX7i2y/n85cczMIdraCg8v6L9YdfwclG47P2Bvwjrs3BLwmgDkikMIA6bx1Q0UIWmg72dbYQZRnT0iQ9lmwGSaF4muqvzqK8/WG/06G+N2V9TfZxVgJ1C7gXZBimpyajPRXUkb7hPEMTWXH1VuOmCJdHj+2pQwk54L+PPLHwK2Jq+XzOJBUZFrQYtCTXvS7uNzfHtA3B2cU9HlQ6ouJXcqWljctWPlDzb7WslCnJqQQNtKwIxpca2w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YfFCGRqL4+SqTifRbis6dh9KH+ZoI0SIxqnFUokiL9jiC29UVZId9fCdAR/pK7vmpqPzM38zRI/7i9plCL6b323Gyv7o2yLfq6GS3S5M1N04iHxq/l+h+wtxBsbJa/BPyoRbTeHBCKNUZLv4xT3rDkimrA4pGdV2+kYOMKU9bGbLU80BMTXPwdWUuO7p1fL0fRePbIq5QXT5D0JGS6jX2VZY/jddzXrRd4VQvcaL/nZStqgUdHyhQ8ypxbX2jEm8/ffaPDps8Vki8mhcG8Ar1icvwG8itxIorAm9/TDCFqoa0BLX3Z+mTWMMuDrY69tMMrDH3njrQfv+Qd7ntEsIOA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Wei Liu <wl@xxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 18 Nov 2021 09:50:53 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.11.2021 10:34, Roger Pau Monné wrote:
> On Thu, Nov 18, 2021 at 09:51:52AM +0100, Jan Beulich wrote:
>> On 18.11.2021 09:33, Roger Pau Monné wrote:
>>> On Thu, Nov 04, 2021 at 01:17:53PM +0100, Jan Beulich wrote:
>>>> On 04.11.2021 11:48, Andrew Cooper wrote:
>>>>> If your answer is "well actually, we didn't mean to say 'if a GSI is
>>>>> mapped' in the comment, and here's a different predicate which actually
>>>>> inspects the state of a dpci object for validity", then fine -  that
>>>>> will shut the compiler up because you're no longer checking for the
>>>>> NULLness of a pointer to a sub-object of a non-NULL pointer, but that's
>>>>> a bugfix which needs backporting several releases too.
>>>>>
>>>>> The current logic is not correct, and does not become correct by trying
>>>>> pass blame to the compiler.
>>>>
>>>> I have yet to understand in which way you deem the current logic to not
>>>> be correct. I'm sorry for being dense.
>>>>
>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102967 is the GCC bug, but
>>>>> the result of it was them persuading me that the diagnostic was
>>>>> legitimate, even if currently expressed badly.  They've agreed to fix
>>>>> how it is expressed, but I doubt you'll persuade them that the trigger
>>>>> for the diagnostic in the first place was wrong.
>>>>
>>>> Well, thanks for the pointer in any event. I've commented there as well.
>>>
>>> Did we get any resolution out of this?
>>
>> I don't think we did. I'm still struggling to understand Andrew's way
>> of thinking.
> 
> What about the GCC bug report?
> 
> Ultimately we need GCC people to make the check less restrictive or we
> need a way to rework the code in a way that doesn't trigger it, either
> Andrew's proposal or something else.
> 
>>> It would be good IMO if we could build out of the box with GCC 12
>>> instead of having to backport fixes later on.
>>
>> I guess gcc12 is too far from getting released that there could be any
>> guarantee for no further issues to get exposed by that point. It has
>> also been common for us to backport fixes and workarounds when new
>> compiler versions appear.
>>
>> I could agree to being proactive if the change to make to our code was
>> uncontroversial.
> 
> OK, but unless GCC changes their mind we are likely to have this
> conversation again in the future, so we might be just delaying the
> inevitable.

Yes, but we apparently need time to settle on how to work around the
issue. I was actually surprised Andrew was able to talk you into
going the chosen route despite your open-coding concerns, which I
share. In the course of the discussion at least one alternative
approach was already outlined, iirc.

Jan




 


Rackspace

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