From: David Gibson <david@gibson.dropbear.id.au>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
Alexander Graf <agraf@suse.de>
Subject: Re: [Qemu-devel] [PATCH qemu v2] spapr/target-ppc/kvm: Only add hcall-instructions if KVM supports it
Date: Mon, 21 Mar 2016 15:17:47 +1100 [thread overview]
Message-ID: <20160321041747.GF23586@voom.redhat.com> (raw)
In-Reply-To: <1458526442-2125-1-git-send-email-aik@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
On Mon, Mar 21, 2016 at 01:14:02PM +1100, Alexey Kardashevskiy wrote:
> ePAPR defines "hcall-instructions" device-tree property which contains
> code to call hypercalls in ePAPR paravirtualized guests. In general
> pseries guests should not be using this facility (as there is sPAPR
> interface) and this property should not be present in the device tree
> for pseries guests.
>
> However a while ago this interface was chosen to implement a hypervisor
> interface to speed up PR KVM guests and since then the property is always
> present in the device tree. All KVM guests use it at least to read features
> via the KVM_HC_FEATURES hypercall.
>
> The property is populated by the code returned from the KVM's
> KVM_PPC_GET_PVINFO ioctl; if not implemented in the KVM, QEMU writes there
> "li r3, -1; nop; nop; nop". If QEMU does not create the property, and
> the guest kernel is compiled with CONFIG_EPAPR_PARAVIRT (which is
> normally the case), there is exactly the same stub at
> @epapr_hypercall_start already.
>
> Rather than maintaining the property (which used to be BE only; then was
> fixed to be endian-agnostic) and confusing the guest (which might think
> there is ePAPR host while there is none), it makes sense not to create
> the property in the device tree in the first place if the host kernel
> does not implement it.
>
> This changes kvmppc_get_hypercall() to return 1 if the host kernel
> does not implement KVM_CAP_PPC_GET_PVINFO. The caller can use it to decide
> on whether to create the property or not.
>
> This changes the pseries machine to not create the property if KVM does
> not implement KVM_PPC_GET_PVINFO. In practice this means that from now
> on the property will not be created if either HV KVM or TCG is used.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Further reworded the commit message and merged to ppc-for-2.6.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
prev parent reply other threads:[~2016-03-21 4:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-21 2:14 [Qemu-devel] [PATCH qemu v2] spapr/target-ppc/kvm: Only add hcall-instructions if KVM supports it Alexey Kardashevskiy
2016-03-21 4:17 ` David Gibson [this message]
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=20160321041747.GF23586@voom.redhat.com \
--to=david@gibson.dropbear.id.au \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.