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 03CE2C433FE for ; Mon, 7 Dec 2020 18:29:14 +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 4407D23877 for ; Mon, 7 Dec 2020 18:29:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4407D23877 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]:43366 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kmLG3-0002j1-Ia for qemu-devel@archiver.kernel.org; Mon, 07 Dec 2020 13:29:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmL5g-0004Jw-J5 for qemu-devel@nongnu.org; Mon, 07 Dec 2020 13:18:28 -0500 Received: from mx2.suse.de ([195.135.220.15]:60820) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kmL5d-0006o6-SV for qemu-devel@nongnu.org; Mon, 07 Dec 2020 13:18:28 -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 841DEAD6A; Mon, 7 Dec 2020 18:18:24 +0000 (UTC) Subject: Re: [PATCH] target/arm: do not use cc->do_interrupt for KVM directly To: Peter Maydell , Eduardo Habkost References: <20201207084042.7690-1-cfontana@suse.de> <20201207174916.GD1289986@habkost.net> From: Claudio Fontana Message-ID: <08bd6211-1ac8-593c-0d95-a8b26a1b3745@suse.de> Date: Mon, 7 Dec 2020 19:18:23 +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: 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: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , =?UTF-8?Q?Alex_Benn=c3=a9e?= , QEMU Developers , Dongjiu Geng Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 12/7/20 7:07 PM, Peter Maydell wrote: > On Mon, 7 Dec 2020 at 17:49, Eduardo Habkost wrote: >> arm_v7m_class_init() (used by cortex-* CPU models) overrides it. >> Those CPU models as "TCG CPUs" in the code, but I don't see what >> makes them TCG-specific. > > They're TCG specific because the Arm Virtualization Extension > is for A-profile only and only supports virtualization of > A-profile CPUs. You can't accelerate an M-profile CPU with it. > (Similarly, you can't use the Virtualization Extension to > accelerate a pre-v7 CPU, which is why CPUs like the arm1176 > are also TCG-only, and you can't use it to accelerate a CPU > which has TrustZone enabled.) > > (M-profile CPUs override cc->do_interrupt() because their > exception and interrupt handling logic is totally different > to A-profile.) > >> What exactly is the expected behavior >> if using, e.g., "-cpu cortex-m33 -accel kvm"? > > It ought to print a useful error message telling you > that that CPU type isn't compatible with KVM. > > As it happens, you get an assertion failure for cortex-m33: > > $ ./build/all/qemu-system-aarch64 -accel kvm -M mps2-an505 -display none > qemu-system-aarch64: ../../softmmu/physmem.c:745: > cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()' > failed. > Aborted > > because the M33 has TrustZone enabled (which is not compatible > with KVM) and we don't check that before we hit the assertion. > We should fix that :-) > > If you try it with a non-TrustZone M-profile core like the M3 then > you do get a better error message: > > $ ./build/all/qemu-system-aarch64 -accel kvm -M mps2-an385 -display none > qemu-system-aarch64: KVM is not supported for this guest CPU type > qemu-system-aarch64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): > Invalid argument > > If you try this with the "virt" board then you'll run into the > virt board's own sanity checking of CPU types instead: > > $ ./build/all/qemu-system-aarch64 -accel kvm -M virt -cpu cortex-m33 > -display none > qemu-system-aarch64: mach-virt: CPU type cortex-m33-arm-cpu not supported > > All of that said, I think I agree with you -- we have this > indirect mechanism for invoking class methods on the CPU > object, why is it necessary for this KVM-specific code to > call the implementation function directly? > > thanks > -- PMM > Hi Peter, the initial attempt there was to mark do_interrupt as a TCG-only operation, to move to a separate tcg_ops structure in CPUClass like for the others, but countrary to the other ops I noticed that ARM is the only target that is calling cc->do_interrupt() for KVM too. I might have to either leave do_interrupt() out of the refactoring, or find a way to avoid accessing cc->do_interrupt on KVM. Thanks, Claudio