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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 23884C433E0 for ; Thu, 11 Feb 2021 13:49:52 +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 A4A9164DEE for ; Thu, 11 Feb 2021 13:49:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A4A9164DEE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36604 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lACLu-00021P-LK for qemu-devel@archiver.kernel.org; Thu, 11 Feb 2021 08:49:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lABpR-0005Xk-N2 for qemu-devel@nongnu.org; Thu, 11 Feb 2021 08:16:18 -0500 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:38465) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lABpO-00075n-7c for qemu-devel@nongnu.org; Thu, 11 Feb 2021 08:16:17 -0500 Received: by mail-ej1-x62c.google.com with SMTP id bl23so10008270ejb.5 for ; Thu, 11 Feb 2021 05:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tWxorh/X8/6luqEWfHVFvTNKWGTDatoq4XOZ0BUEycU=; b=bL437tQ4qAndHywaeXhJBXiiF+zQs/6+vZBEasq2WZH4OcI6QlUibykO9+iLHT5Tt1 /6imvxxJWjvTM2+MwPXyhskSfdNhwyd03f6owDSw3AQAROgDjs+HjnUPFyELN7WBcNBC 5aG2c10uaoUVN94cgjYpbV8iun1POUZN2ygLZMg8nxlFFeUzwn7AJ6TnNs4c9XpVZii/ fal98YvqxoyUEipFLplWpaET6fmymhLCkglrGu9mhLZYMFK7Gz9XRq4rWGaaN6/LOLJS G2NwV49Kjlr0sKBjNvGp1JEA3X+65pw2fZRRXs4TQQShPEvaFx9jmJ0rBwr8GmUmA7Ox 3GEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tWxorh/X8/6luqEWfHVFvTNKWGTDatoq4XOZ0BUEycU=; b=ITgEdm8csmJ/dpSZhJxj6z3Pc7v53QczO7FFkjhWppp2Ase359nBh9DuVgMLIcZFHG Ga1joULaffEIJt9xoyzhvQnQOvcy0MB+r928ROmlJy3T8w5neb7gHp1J09KGzcV/KGMz eCKclL0ZHFeCSAdzX1mqcDU57Zr78/BSf5ZGOsN4jdZ7LYxnYVTuFOV8Ge74PYoD3mtJ GqtWBDL2nJEwbDB18gqE6XxLszStgsEO23HZqoWC+uJGXfSpJmEwMYi7bIDM9l3uL35K SPaCwYJdt6i63OtTIIWDyojpclmGR7Pd1DGEE8QcRH5vdh8M0awIAZTHUpUEcnCyliMG Dxiw== X-Gm-Message-State: AOAM53170u7GRQN2v2m0dt0R+1AI1ex/BR9Mmv6eQPY+RRH/KGyNHBfn 4tIBfVCUAwyTOWmIVpb1oxKoGh0WYEaSBxno09iFLg== X-Google-Smtp-Source: ABdhPJz/KDj+QdgAwQCkqTOGlqSTVM9tJxQx1adRXdYbUY1V1AYTG3jsB1L7c0jsOzJrmFNe2wyRZhLEKyzkePh8aRU= X-Received: by 2002:a17:906:2e4f:: with SMTP id r15mr8489803eji.407.1613049372166; Thu, 11 Feb 2021 05:16:12 -0800 (PST) MIME-Version: 1.0 References: <20210120224444.71840-1-agraf@csgraf.de> <20210120224444.71840-8-agraf@csgraf.de> <298dcf49-1a99-9406-275f-b05c8befd13b@csgraf.de> <37018444-82a8-96c0-b5ce-da056646a1b8@csgraf.de> In-Reply-To: <37018444-82a8-96c0-b5ce-da056646a1b8@csgraf.de> From: Peter Maydell Date: Thu, 11 Feb 2021 13:16:00 +0000 Message-ID: Subject: Re: [PATCH v6 07/11] hvf: Add Apple Silicon support To: Alexander Graf Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::62c; envelope-from=peter.maydell@linaro.org; helo=mail-ej1-x62c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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: Eduardo Habkost , Richard Henderson , QEMU Developers , Cameron Esfahani , Roman Bolshakov , qemu-arm , Frank Yang , Paolo Bonzini , Peter Collingbourne Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 11 Feb 2021 at 13:06, Alexander Graf wrote: > > > On 10.02.21 23:39, Peter Maydell wrote: > > On Wed, 10 Feb 2021 at 22:21, Alexander Graf wrote: > >> > >> On 28.01.21 16:52, Peter Maydell wrote: > >>> On Wed, 20 Jan 2021 at 22:44, Alexander Graf wrote: > >>>> + break; > >>>> + case EC_AA64_SMC: > >>>> + cpu_synchronize_state(cpu); > >>>> + if (arm_is_psci_call(arm_cpu, EXCP_SMC)) { > >>>> + arm_handle_psci_call(arm_cpu); > >>> Have you checked that all the PSCI code really can cope > >>> with being called from a non-TCG accelerator? (As an example > >>> the CPU_SUSPEND implementation calls the TCG wfi helper...) > >> > >> I have not explicitly tried it, but I don't see why the TCG > >> implementation of wfi should in principle break with hvf. > > Because the TCG implementation of wfi is "set some state fields > > and then longjump out to the TCG exec_cpu code-execution loop", > > and hvf doesn't use that loop. > > > I can confirm that it breaks, but are you really sure about the longjmp > not working? > > What would you prefer instead? Duplicate the PSCI implementation for HVF? I would prefer that you worked through the details. In other words, mostly my concerns with this series are that it feels like it has a lot of quick-hack "this makes the guests I tested boot" stuff in it. Examples include this PSCI handling, the WFI/timer interrupt bits, the way the GIC is done, and the "let's ignore bogus SMC calls" below. > >>> This should inject an UNDEF exception into the guest. (Compare > >>> the pre_smc helper in target/arm/op_helper.c for TCG.) > >> > >> That would break Windows, which is one of the main use cases for hvf > >> support in QEMU. > > Why is Windows making bogus SMC calls ? > > > Let me have a quick at my crystal ball ... mmmmmmhhhh ... it's a bit > blurry unfortunately. > > I really don't think I'm the right person to answer that question :). > But the Windows loader does invoke weird SMC calls on boot: Does it boot under TCG ? Under KVM ? If there's an SMC API that we ought to be implementing but aren't, then we should implement it consistently. If the guest is doing something wrong, we shouldn't put in fudges to work around that. Once that kind of hack gets into the codebase it is practically impossible to ever get rid of it. thanks -- PMM