From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80C86C433E0 for ; Fri, 29 Jan 2021 09:03:57 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E63A664E15 for ; Fri, 29 Jan 2021 09:03:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E63A664E15 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:45248 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l5Ph5-0005lo-Ub for qemu-devel@archiver.kernel.org; Fri, 29 Jan 2021 04:03:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40276) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l5Pdx-0003WI-5v for qemu-devel@nongnu.org; Fri, 29 Jan 2021 04:00:41 -0500 Received: from mx2.suse.de ([195.135.220.15]:39622) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l5Pdq-0005mT-O7 for qemu-devel@nongnu.org; Fri, 29 Jan 2021 04:00:40 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id C000DAF7F; Fri, 29 Jan 2021 09:00:29 +0000 (UTC) Subject: Re: [PATCH v14 15/22] cpu: tcg_ops: move to tcg-cpu-ops.h, keep a pointer in CPUClass To: Richard Henderson , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Paolo Bonzini , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , Eduardo Habkost , Peter Maydell References: <20210128092814.8676-1-cfontana@suse.de> <20210128092814.8676-16-cfontana@suse.de> <171c61e2-36f2-86cf-a5e0-15806cccfd0b@linaro.org> From: Claudio Fontana Message-ID: Date: Fri, 29 Jan 2021 10:00:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <171c61e2-36f2-86cf-a5e0-15806cccfd0b@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=195.135.220.15; envelope-from=cfontana@suse.de; helo=mx2.suse.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Laurent Vivier , Thomas Huth , Alistair Francis , Roman Bolshakov , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 1/29/21 1:31 AM, Richard Henderson wrote: > On 1/27/21 11:28 PM, Claudio Fontana wrote: >> + /* >> + * NB: this should be covered by CONFIG_TCG, but it is unsafe to do it here, >> + * as this header is included by both ss_specific and ss_common code, >> + * leading to potential differences in the data structure between modules. >> + * We could always keep it last, but it seems safer to just leave this >> + * pointer NULL for non-TCG. >> + */ >> + struct TCGCPUOps *tcg_ops; > > Sorry, I'm going to unqueue the patch set. > > I first thought this was fixing up something done already, fixing an existing bug. > > But it's something done in patch 1, and therefore the patch set needs to be > re-worked to use this pointer to begin, for the exact reasons detailed above. > Otherwise it would appear this breaks bisection. > > > r~ > Hi Richard, I made sure that the previous patches actually work in practice, ie the issue mentioned there does not actually happen in practice, due to the purposeful placement of the field in the structure that might be seen by one module and not the other at the end of the structure, so no problem happens, and bisection is actually safe. The warning and the change is due to the fact that changing things in the way this patch suggests makes it safer from _future changes_, in which someone might add a new field at the end of the structure, after the conditional fields, which would actually break things. Do you think I should redo the series anyway? I would have started this way in the first place, but I tried not to redo Eduardo's work. Let me know what you think, Thanks, Claudio