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=-10.5 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 69406C433E0 for ; Wed, 10 Feb 2021 21:36:10 +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 0820D64E66 for ; Wed, 10 Feb 2021 21:36:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0820D64E66 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=csgraf.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:43348 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9x9d-0006PB-0L for qemu-devel@archiver.kernel.org; Wed, 10 Feb 2021 16:36:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9x8B-0005jI-Mr; Wed, 10 Feb 2021 16:34:39 -0500 Received: from mail.csgraf.de ([85.25.223.15]:40444 helo=zulu616.server4you.de) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9x89-0005uQ-LE; Wed, 10 Feb 2021 16:34:39 -0500 Received: from Alexanders-Mac-mini.local (unknown [188.138.100.120]) by csgraf.de (Postfix) with UTF8SMTPSA id 4973C60803D4; Wed, 10 Feb 2021 22:34:31 +0100 (CET) Message-ID: Date: Wed, 10 Feb 2021 22:34:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:86.0) Gecko/20100101 Thunderbird/86.0 Subject: Re: [PATCH v6 06/11] hvf: Simplify post reset/init/loadvm hooks Content-Language: en-US To: Peter Maydell References: <20210120224444.71840-1-agraf@csgraf.de> <20210120224444.71840-7-agraf@csgraf.de> From: Alexander Graf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=85.25.223.15; envelope-from=agraf@csgraf.de; helo=zulu616.server4you.de 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, NICE_REPLY_A=-0.211, 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: 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 28.01.21 16:28, Peter Maydell wrote: > On Wed, 20 Jan 2021 at 22:44, Alexander Graf wrote: >> The hooks we have that call us after reset, init and loadvm really all >> just want to say "The reference of all register state is in the QEMU >> vcpu struct, please push it". >> >> We already have a working pushing mechanism though called cpu->vcpu_dirty, >> so we can just reuse that for all of the above, syncing state properly the >> next time we actually execute a vCPU. >> >> This fixes PSCI resets on ARM, as they modify CPU state even after the >> post init call has completed, but before we execute the vCPU again. >> >> To also make the scheme work for x86, we have to make sure we don't >> move stale eflags into our env when the vcpu state is dirty. >> >> Signed-off-by: Alexander Graf >> Reviewed-by: Roman Bolshakov >> Tested-by: Roman Bolshakov > What's the difference between HVF and KVM that means this code > doesn't have the same structure the KVM code does here? The main reason is that with KVM, responsibility of register reset is shared between kernel and user space. With HVF, user space has everything under full control, so all we need to say is "user space is your reference now". While with KVM, we may need to still say "KVM state is your reference, because it will do the register reset on behalf of us". Alex