Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp4959248ybv; Mon, 17 Feb 2020 09:14:08 -0800 (PST) X-Google-Smtp-Source: APXvYqzOTRlS6V1clX9YePcnoeLZSuBPA+8uCZSfhBUd+2VD7qt3SbM+RckhiVc1ij1zT68Pya0U X-Received: by 2002:a05:6830:210d:: with SMTP id i13mr12903478otc.192.1581959648605; Mon, 17 Feb 2020 09:14:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581959648; cv=none; d=google.com; s=arc-20160816; b=iBn8/izbT+oyQfDXhMvUjeT6Un37mOjqWml30gqOwvr3uGYSmLiy8q0NbnQQEFihwj bYC8OWpq9OzI3OPs5trlPC931J20sgQTz/fy0+tMmkFXxgbNN5wMh0huMguLQQtcyD2k tJGQHtVn8Gt5EJ6E/4R3/W9VzLXbBQ01nHzMg81TGMFqbzAvDoQzxLqM66NZCXZHQ5Bv FRIPeuMLOFWOZ24xFr0opFl92XvGpZI2r8u74HoCJYCuR022D4g1BukFntL6PstfBEL/ z/28hIHP8m3MrhegOTTnLvl/RqllLdbmcelWVJ5nMe08dRQ5f784JLugKsWF6F516ZR5 Ahjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=7p5g9/+JuQI5dVBHZjO5Q9kWlIBYXtB5HG4luX7GEwo=; b=Vh0RpfpTbDQliYlsfdzWFhA/faXiosi0UPNgZH/OtKsdb6LKp3rXMLH+N2vD8IIJgD UA+ICnXwfQzFNYeIvbsO3rNCn7c7ZwVw7yf0GGWk+91JAyeqGfxjKT/lpf5n3xgq+Wpf QgpCHaLPKMUO+FCleBVh3JhHXijrXepqmqFOEaGIbO0oPPuyt7pA6nX/Vot6D8NLs3by O+OMLW4DRl0tfKanciNWFOLfCG6BH7z1LY93gE2OT2XEEnoMOoKu7BNC3BHov1z7iu3g BnsGygY9Qmuao60heozU6o4KSHfsgG5aiGj7Td87VeeLVvVkrEu89KsCYO1I2mE3DUA6 2wXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=c5iSXndv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m4si450184otn.281.2020.02.17.09.13.56; Mon, 17 Feb 2020 09:14:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=c5iSXndv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729541AbgBQRNA (ORCPT + 99 others); Mon, 17 Feb 2020 12:13:00 -0500 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:31243 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728519AbgBQRNA (ORCPT ); Mon, 17 Feb 2020 12:13:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581959579; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7p5g9/+JuQI5dVBHZjO5Q9kWlIBYXtB5HG4luX7GEwo=; b=c5iSXndv6kPklkKC/u67PoXw+dlN/Sf9IGEUSbtQpwTnZ1IUnx14XoCa5DgemRgbcKggJo FjQVOmlSgQOwz74yaXjL73bpZLR9hj2GYtR15yBPPNp4+L4FsodTzMSwtp3VK8hXv8HkiL t7djvLmLnQZqIZtGvLkNTG7zOod4wWU= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-215-KSMpw-QbOpewWzN_otF1Kg-1; Mon, 17 Feb 2020 12:12:57 -0500 X-MC-Unique: KSMpw-QbOpewWzN_otF1Kg-1 Received: by mail-wr1-f70.google.com with SMTP id z15so9301530wrw.0 for ; Mon, 17 Feb 2020 09:12:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7p5g9/+JuQI5dVBHZjO5Q9kWlIBYXtB5HG4luX7GEwo=; b=MZj9LRUJW9YoIKbPNo7hbFcrQzNylq+yRFm3J2pl/3FyP6LIVsU7ZPAMZ7zoBmyeyx T09ixOLk3pfa83Rf0WwNtgT5jrRLOW3J8Ey4NuNrju8mgwlL/ByXrO5haC3Ues57izKd zuWkWP2NZsD17mNz4w+itwh3niAf84Z0NXeUFIC0MIF9dcaFsHTEMLng5lkXgkQpOFDO ZoulUdhW3EwGfsszfKSnXiu5DEDSiKnYuuZl61wF/q0Na1mmwiVjUmM00gaDglu5xnd5 wtK8AbtrUa/MVu5arqiTTYNtlktFSZZM3UO1wIOS7RBdsBUaTeMHq1CC31u8GAuBgCW8 mZLg== X-Gm-Message-State: APjAAAUY0Z7EfSQK2gzW92sIfb8DxTzIu2mbFY3ZIO1ZkBEG7/tcNp5+ EcUU5XHazcjpjghY373/5VaEJptOeVb98aIULH6tDfKaUFZFeVJuLJEr0ok0PvL2/ySkIVY8W1F dBQuMBXNaHw8AVc9Ce6KAsBnV X-Received: by 2002:adf:f401:: with SMTP id g1mr22756290wro.129.1581959576250; Mon, 17 Feb 2020 09:12:56 -0800 (PST) X-Received: by 2002:adf:f401:: with SMTP id g1mr22756263wro.129.1581959575982; Mon, 17 Feb 2020 09:12:55 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:59c7:c3ee:2dec:d2b4? ([2001:b07:6468:f312:59c7:c3ee:2dec:d2b4]) by smtp.gmail.com with ESMTPSA id b18sm1907565wru.50.2020.02.17.09.12.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 17 Feb 2020 09:12:55 -0800 (PST) Subject: Re: [PATCH v2] kvm/emulate: fix a -Werror=cast-function-type To: Qian Cai Cc: sean.j.christopherson@intel.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, joro@8bytes.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org References: <1581958106-16668-1-git-send-email-cai@lca.pw> From: Paolo Bonzini Message-ID: Date: Mon, 17 Feb 2020 18:12:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <1581958106-16668-1-git-send-email-cai@lca.pw> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/02/20 17:48, Qian Cai wrote: > arch/x86/kvm/emulate.c: In function 'x86_emulate_insn': > arch/x86/kvm/emulate.c:5686:22: error: cast between incompatible > function types from 'int (*)(struct x86_emulate_ctxt *)' to 'void > (*)(struct fastop *)' [-Werror=cast-function-type] > rc = fastop(ctxt, (fastop_t)ctxt->execute); > > Fix it by using an unnamed union of a (*execute) function pointer and a > (*fastop) function pointer. > > Fixes: 3009afc6e39e ("KVM: x86: Use a typedef for fastop functions") > Suggested-by: Paolo Bonzini > Signed-off-by: Qian Cai > --- > > v2: use an unnamed union. > > arch/x86/include/asm/kvm_emulate.h | 13 ++++++++++++- > arch/x86/kvm/emulate.c | 36 ++++++++++++++---------------------- > 2 files changed, 26 insertions(+), 23 deletions(-) > > diff --git a/arch/x86/include/asm/kvm_emulate.h b/arch/x86/include/asm/kvm_emulate.h > index 03946eb3e2b9..2a8f2bd2e5cf 100644 > --- a/arch/x86/include/asm/kvm_emulate.h > +++ b/arch/x86/include/asm/kvm_emulate.h > @@ -292,6 +292,14 @@ enum x86emul_mode { > #define X86EMUL_SMM_MASK (1 << 6) > #define X86EMUL_SMM_INSIDE_NMI_MASK (1 << 7) > > +/* > + * fastop functions are declared as taking a never-defined fastop parameter, > + * so they can't be called from C directly. > + */ > +struct fastop; > + > +typedef void (*fastop_t)(struct fastop *); > + > struct x86_emulate_ctxt { > const struct x86_emulate_ops *ops; > > @@ -324,7 +332,10 @@ struct x86_emulate_ctxt { > struct operand src; > struct operand src2; > struct operand dst; > - int (*execute)(struct x86_emulate_ctxt *ctxt); > + union { > + int (*execute)(struct x86_emulate_ctxt *ctxt); > + fastop_t fop; > + }; > int (*check_perm)(struct x86_emulate_ctxt *ctxt); > /* > * The following six fields are cleared together, > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > index ddbc61984227..dd19fb3539e0 100644 > --- a/arch/x86/kvm/emulate.c > +++ b/arch/x86/kvm/emulate.c > @@ -191,25 +191,6 @@ > #define NR_FASTOP (ilog2(sizeof(ulong)) + 1) > #define FASTOP_SIZE 8 > > -/* > - * fastop functions have a special calling convention: > - * > - * dst: rax (in/out) > - * src: rdx (in/out) > - * src2: rcx (in) > - * flags: rflags (in/out) > - * ex: rsi (in:fastop pointer, out:zero if exception) > - * > - * Moreover, they are all exactly FASTOP_SIZE bytes long, so functions for > - * different operand sizes can be reached by calculation, rather than a jump > - * table (which would be bigger than the code). > - * > - * fastop functions are declared as taking a never-defined fastop parameter, > - * so they can't be called from C directly. > - */ > - > -struct fastop; > - > struct opcode { > u64 flags : 56; > u64 intercept : 8; > @@ -311,8 +292,19 @@ static void invalidate_registers(struct x86_emulate_ctxt *ctxt) > #define ON64(x) > #endif > > -typedef void (*fastop_t)(struct fastop *); > - > +/* > + * fastop functions have a special calling convention: > + * > + * dst: rax (in/out) > + * src: rdx (in/out) > + * src2: rcx (in) > + * flags: rflags (in/out) > + * ex: rsi (in:fastop pointer, out:zero if exception) > + * > + * Moreover, they are all exactly FASTOP_SIZE bytes long, so functions for > + * different operand sizes can be reached by calculation, rather than a jump > + * table (which would be bigger than the code). > + */ > static int fastop(struct x86_emulate_ctxt *ctxt, fastop_t fop); > > #define __FOP_FUNC(name) \ > @@ -5683,7 +5675,7 @@ int x86_emulate_insn(struct x86_emulate_ctxt *ctxt) > > if (ctxt->execute) { > if (ctxt->d & Fastop) > - rc = fastop(ctxt, (fastop_t)ctxt->execute); > + rc = fastop(ctxt, ctxt->fop); > else > rc = ctxt->execute(ctxt); > if (rc != X86EMUL_CONTINUE) > Queued, thank you very much. Paolo