public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Alexander Graf <agraf@suse.de>
Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH 2/3] KVM: PPC: Add SPR emulation exits
Date: Sun, 07 Oct 2012 15:13:16 +0200	[thread overview]
Message-ID: <50717FEC.9030503@redhat.com> (raw)
In-Reply-To: <1349566882-10948-3-git-send-email-agraf@suse.de>

On 10/07/2012 01:41 AM, Alexander Graf wrote:
> SPRs on PowerPC are the equivalent to MSRs on x86. They usually
> control behavior inside a core, so the best place to emulate them
> traditionally has been the kernel side of kvm.
> 
> However, some SPRs should be emulated by user space. For example
> the DBCR0 register which is used for machine reset. Or the interrupt
> acknowledge register on e500 which is tightly integrated with the
> interrupt controller that lives in user space.
> 
> So let's expose "unknown" SPR reads and writes to user space, so that
> it can handle them if it knows what's going on.
> 
> As a nice side effect, we also get a lot better error reporting up
> to user space, since now we actually know when an SPR read/write failed.
> 

We have a similar problem with x86 MSRs.

> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index e726d76..7a35c64 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2253,6 +2253,32 @@ The possible hypercalls are defined in the Power Architecture Platform
>  Requirements (PAPR) document available from www.power.org (free
>  developer registration required to access it).
>  
> +		/* KVM_EXIT_SPR */
> +		struct {
> +			__u64 sprn;
> +			__u64 data;
> +			__u64 msr;
> +			__u8  is_write;
> +#define SPR_STATUS_OK   0
> +#define SPR_STATUS_FAIL 1
> +			__u8  status;
> +		} spr;
> +
> +This is used on PowerPC for Special Purpose Register emulation that
> +the kernel can not deal with.
> +
> +It occurs when the guest triggers an mtspr or mfspr instruction on
> +an SPR that is not handled by kvm's SPR emulation code. In these
> +cases, 'sprn' contains the SPR ID. That ID is target CPU specific.
> +'data' contains the value to write to the SPR when 'is_write'==1 (mtspr)
> +or is used as result buffer for 'is_write'==0 (mfspr). Status is used
> +to tell the kernel that an SPR read/write was successful. It is set to
> +SPR_STATUS_OK by default. If user space fails to emulate an SPR access,
> +it should set it to SPR_STATUS_FAIL, so that the kernel can inject
> +an exception into the guest context. The field 'msr' contains the MSR
> +register state at the point of time the SPR read/write occured. It can
> +be used by user space for permission checks.
> +

Since this happens in the middle of instruction emulation, the same
rules should apply.  Userspace must reenter kvm with the response to the
instruction, and can force an immediate exit by queueing an unmasked signal.


What happens when a future kvm starts emulating an SPR that was
previously emulated in userspace?


-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-10-07 13:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-06 23:41 [PATCH 0/3] KVM: PPC: Enable user space handled SPRs Alexander Graf
2012-10-06 23:41 ` [PATCH 1/3] KVM: PPC: Move mtspr/mfspr emulation into own functions Alexander Graf
2012-10-06 23:41 ` [PATCH 2/3] KVM: PPC: Add SPR emulation exits Alexander Graf
2012-10-07 13:13   ` Avi Kivity [this message]
2012-10-07 13:19     ` Alexander Graf
2012-10-07 13:26       ` Avi Kivity
2012-10-07 13:30         ` Alexander Graf
2012-10-07 13:34           ` Avi Kivity
2012-10-07 13:37             ` Alexander Graf
2012-10-08 20:45           ` Scott Wood
2012-10-08 21:01             ` Alexander Graf
2012-10-08 21:07               ` Scott Wood
2012-10-07 13:26       ` Alexander Graf
2012-10-07 13:30         ` Avi Kivity
2012-10-07 13:33           ` Alexander Graf
2012-10-06 23:41 ` [PATCH 3/3] KVM: PPC: BookE: Forward DBCR0 to user space Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50717FEC.9030503@redhat.com \
    --to=avi@redhat.com \
    --cc=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox