Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751293AbdFBLv7 (ORCPT <rfc822;w@1wt.eu>);
        Fri, 2 Jun 2017 07:51:59 -0400
Received: from mail-wm0-f43.google.com ([74.125.82.43]:37336 "EHLO
        mail-wm0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751154AbdFBLv5 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 2 Jun 2017 07:51:57 -0400
Date: Fri, 2 Jun 2017 13:51:40 +0200
From: Christoffer Dall <cdall@linaro.org>
To: Bandan Das <bsd@redhat.com>
Cc: Jintack Lim <jintack@cs.columbia.edu>, christoffer.dall@linaro.org,
        marc.zyngier@arm.com, pbonzini@redhat.com, rkrcmar@redhat.com,
        linux@armlinux.org.uk, catalin.marinas@arm.com, will.deacon@arm.com,
        vladimir.murzin@arm.com, suzuki.poulose@arm.com, mark.rutland@arm.com,
        james.morse@arm.com, lorenzo.pieralisi@arm.com, kevin.brodsky@arm.com,
        wcohen@redhat.com, shankerd@codeaurora.org, geoff@infradead.org,
        andre.przywara@arm.com, eric.auger@redhat.com,
        anna-maria@linutronix.de, shihwei@cs.columbia.edu,
        linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 07/55] KVM: arm/arm64: Add virtual EL2 state emulation
 framework
Message-ID: <20170602115140.GB397@cbox>
References: <1483943091-1364-1-git-send-email-jintack@cs.columbia.edu>
 <1483943091-1364-8-git-send-email-jintack@cs.columbia.edu>
 <jpg37bj1nj6.fsf@linux.bootlegged.copy>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <jpg37bj1nj6.fsf@linux.bootlegged.copy>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1756
Lines: 53

On Thu, Jun 01, 2017 at 04:05:49PM -0400, Bandan Das wrote:
> Jintack Lim <jintack@cs.columbia.edu> writes:
> ...
> > +/**
> > + * kvm_arm_setup_shadow_state -- prepare shadow state based on emulated mode
> > + * @vcpu: The VCPU pointer
> > + */
> > +void kvm_arm_setup_shadow_state(struct kvm_vcpu *vcpu)
> > +{
> > +	struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
> > +
> > +	ctxt->hw_pstate = *vcpu_cpsr(vcpu);
> > +	ctxt->hw_sys_regs = ctxt->sys_regs;
> > +	ctxt->hw_sp_el1 = ctxt->gp_regs.sp_el1;
> > +}
> > +
> > +/**
> > + * kvm_arm_restore_shadow_state -- write back shadow state from guest
> > + * @vcpu: The VCPU pointer
> > + */
> > +void kvm_arm_restore_shadow_state(struct kvm_vcpu *vcpu)
> > +{
> > +	struct kvm_cpu_context *ctxt = &vcpu->arch.ctxt;
> > +
> > +	*vcpu_cpsr(vcpu) = ctxt->hw_pstate;
> > +	ctxt->gp_regs.sp_el1 = ctxt->hw_sp_el1;
> > +}
> > +
> > +void kvm_arm_init_cpu_context(kvm_cpu_context_t *cpu_ctxt)
> > +{
> > +	cpu_ctxt->hw_sys_regs = &cpu_ctxt->sys_regs[0];
> > +}
> 
> 
> IIUC, the *_shadow_state() functions will set hw_* pointers to
> either point to the "real" state or the shadow state to manage L2 ?
> Maybe, it might make sense to make these function names a little more
> generic since they are not dealing with setting the shadow state
> alone.
> 

The notion of 'shadow state' is borrowed from shadow page tables, in
which you always load some 'shadow copy' of the 'real value' into the
hardware, so the shadow state is the one that's used for execution by
the hardware.

The shadow state may be the same as the VCPU's EL1 state, for example,
or it may be a modified version of the VCPU's EL2 state, for example.

If you have better suggestions for naming, we're open to that though.

Thanks,
-Christoffer