From: Paolo Bonzini <pbonzini@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>, will.deacon@arm.com
Cc: andre.przywara@arm.com, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org, svaidy@linux.vnet.ibm.com,
matt@ozlabs.org
Subject: Re: [PATCH 1/2] powerpc: Define the hcall opcodes & return values we need
Date: Tue, 23 Jun 2015 09:33:41 +0000 [thread overview]
Message-ID: <558927F5.1040401@redhat.com> (raw)
In-Reply-To: <1434698461-15539-1-git-send-email-mpe@ellerman.id.au>
On 19/06/2015 09:21, Michael Ellerman wrote:
> Now that we don't have the kernel header on hand, just define the
> minimum set of hcall opcodes and return values we need in order to
> build.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> powerpc/spapr.h | 25 ++++++++++++++++++++-----
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/powerpc/spapr.h b/powerpc/spapr.h
> index 0537f881c0e4..7a377d093ef4 100644
> --- a/powerpc/spapr.h
> +++ b/powerpc/spapr.h
> @@ -16,17 +16,32 @@
>
> #include <inttypes.h>
>
> -/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */
> -#define __KERNEL__
> -#include <asm/hvcall.h>
> -#undef __KERNEL__
> -
This thing is exactly why I think kvmtool's life in the kernel tree was
harmful.
Why wasn't instead H_* just moved to a uapi/ header?!?!? Can you do
that now?
Thanks,
Paolo
> #include "kvm/kvm.h"
> #include "kvm/kvm-cpu.h"
>
> typedef unsigned long target_ulong;
> typedef uintptr_t target_phys_addr_t;
>
> +#define H_SUCCESS 0
> +#define H_HARDWARE -1 /* Hardware error */
> +#define H_FUNCTION -2 /* Function not supported */
> +#define H_PARAMETER -4 /* Parameter invalid, out-of-range or conflicting */
> +
> +#define H_SET_DABR 0x28
> +#define H_LOGICAL_CI_LOAD 0x3c
> +#define H_LOGICAL_CI_STORE 0x40
> +#define H_LOGICAL_CACHE_LOAD 0x44
> +#define H_LOGICAL_CACHE_STORE 0x48
> +#define H_LOGICAL_ICBI 0x4c
> +#define H_LOGICAL_DCBF 0x50
> +#define H_GET_TERM_CHAR 0x54
> +#define H_PUT_TERM_CHAR 0x58
> +#define H_CPPR 0x68
> +#define H_EOI 0x64
> +#define H_IPI 0x6c
> +#define H_XIRR 0x74
> +#define MAX_HCALL_OPCODE H_XIRR
> +
> /*
> * The hcalls above are standardized in PAPR and implemented by pHyp
> * as well.
>
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>, will.deacon@arm.com
Cc: andre.przywara@arm.com, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org, svaidy@linux.vnet.ibm.com,
matt@ozlabs.org
Subject: Re: [PATCH 1/2] powerpc: Define the hcall opcodes & return values we need
Date: Tue, 23 Jun 2015 11:33:41 +0200 [thread overview]
Message-ID: <558927F5.1040401@redhat.com> (raw)
In-Reply-To: <1434698461-15539-1-git-send-email-mpe@ellerman.id.au>
On 19/06/2015 09:21, Michael Ellerman wrote:
> Now that we don't have the kernel header on hand, just define the
> minimum set of hcall opcodes and return values we need in order to
> build.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
> powerpc/spapr.h | 25 ++++++++++++++++++++-----
> 1 file changed, 20 insertions(+), 5 deletions(-)
>
> diff --git a/powerpc/spapr.h b/powerpc/spapr.h
> index 0537f881c0e4..7a377d093ef4 100644
> --- a/powerpc/spapr.h
> +++ b/powerpc/spapr.h
> @@ -16,17 +16,32 @@
>
> #include <inttypes.h>
>
> -/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */
> -#define __KERNEL__
> -#include <asm/hvcall.h>
> -#undef __KERNEL__
> -
This thing is exactly why I think kvmtool's life in the kernel tree was
harmful.
Why wasn't instead H_* just moved to a uapi/ header?!?!? Can you do
that now?
Thanks,
Paolo
> #include "kvm/kvm.h"
> #include "kvm/kvm-cpu.h"
>
> typedef unsigned long target_ulong;
> typedef uintptr_t target_phys_addr_t;
>
> +#define H_SUCCESS 0
> +#define H_HARDWARE -1 /* Hardware error */
> +#define H_FUNCTION -2 /* Function not supported */
> +#define H_PARAMETER -4 /* Parameter invalid, out-of-range or conflicting */
> +
> +#define H_SET_DABR 0x28
> +#define H_LOGICAL_CI_LOAD 0x3c
> +#define H_LOGICAL_CI_STORE 0x40
> +#define H_LOGICAL_CACHE_LOAD 0x44
> +#define H_LOGICAL_CACHE_STORE 0x48
> +#define H_LOGICAL_ICBI 0x4c
> +#define H_LOGICAL_DCBF 0x50
> +#define H_GET_TERM_CHAR 0x54
> +#define H_PUT_TERM_CHAR 0x58
> +#define H_CPPR 0x68
> +#define H_EOI 0x64
> +#define H_IPI 0x6c
> +#define H_XIRR 0x74
> +#define MAX_HCALL_OPCODE H_XIRR
> +
> /*
> * The hcalls above are standardized in PAPR and implemented by pHyp
> * as well.
>
next prev parent reply other threads:[~2015-06-23 9:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 7:21 [PATCH 1/2] powerpc: Define the hcall opcodes & return values we need Michael Ellerman
2015-06-19 7:21 ` Michael Ellerman
2015-06-19 7:21 ` [PATCH 2/2] powerpc: Enable 32-bit build Michael Ellerman
2015-06-19 7:21 ` Michael Ellerman
2015-06-19 7:40 ` [PATCH 1/2] powerpc: Define the hcall opcodes & return values we need Michael Ellerman
2015-06-19 7:40 ` Michael Ellerman
2015-06-19 10:35 ` Will Deacon
2015-06-19 10:35 ` Will Deacon
2015-06-23 9:33 ` Paolo Bonzini [this message]
2015-06-23 9:33 ` Paolo Bonzini
2015-06-23 10:05 ` Michael Ellerman
2015-06-23 10:05 ` Michael Ellerman
2015-06-23 10:31 ` Andre Przywara
2015-06-23 10:31 ` Andre Przywara
2015-06-23 10:33 ` Paolo Bonzini
2015-06-23 10:33 ` Paolo Bonzini
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=558927F5.1040401@redhat.com \
--to=pbonzini@redhat.com \
--cc=andre.przywara@arm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=matt@ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=svaidy@linux.vnet.ibm.com \
--cc=will.deacon@arm.com \
/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.