[1/2] powerpc: Define the hcall opcodes & return values we need

Message ID 1434698461-15539-1-git-send-email-mpe@ellerman.id.au
State Not Applicable, archived
Headers show

Commit Message

Michael Ellerman June 19, 2015, 7:21 a.m.
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(-)

Comments

Michael Ellerman June 19, 2015, 7:40 a.m. | #1
On Fri, 2015-06-19 at 17:21 +1000, 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.

Hi Andre,

I hope you don't mind me jumping in here but I thought I should help out rather
than just sending feedback :)

I also should have said that these are on top of e96a27a10732 from Will's tree.

cheers


--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Will Deacon June 19, 2015, 10:35 a.m. | #2
On Fri, Jun 19, 2015 at 08:21:00AM +0100, 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.

Thanks Michael!

I pushed both of these out.

Will
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paolo Bonzini June 23, 2015, 9:33 a.m. | #3
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.
> 
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Michael Ellerman June 23, 2015, 10:05 a.m. | #4
On Tue, 2015-06-23 at 11:33 +0200, Paolo Bonzini wrote:
> On 19/06/2015 09:21, Michael Ellerman wrote:
> > 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.

Harmful is a bit of an overstatement. Though I agree that was a bit of a hack.

> Why wasn't instead H_* just moved to a uapi/ header?!?!?  Can you do
> that now?

Because it's not part of the kernel API, never was, still isn't.

It *is* part of the hypervisor API, but it's not Linux's job to export that and
deal with the fallout if it was ever changed.

cheers


--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Andre Przywara June 23, 2015, 10:31 a.m. | #5
Hi,

On 23/06/15 11:05, Michael Ellerman wrote:
> On Tue, 2015-06-23 at 11:33 +0200, Paolo Bonzini wrote:
>> On 19/06/2015 09:21, Michael Ellerman wrote:
>>> 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.
> 
> Harmful is a bit of an overstatement. Though I agree that was a bit of a hack.
> 
>> Why wasn't instead H_* just moved to a uapi/ header?!?!?  Can you do
>> that now?
> 
> Because it's not part of the kernel API, never was, still isn't.

Technically it may not - if I get this correctly it is more a platform
API defined by the architecture, like ACPI or PSCI on ARM.
But if I get this correctly Linux re-uses those definitions in the KVM
API, by piggy-backing on the existing hypercalls. Please correct me if I
am wrong here, I am looking at arch/powerpc/kvm/book3s_hv.c, where it
seems to trap those hypercalls.

So I think that - though not originally invented or defined by Linux -
it should export those definitions that KVM (re-)uses.
QEMU also has a header file duplicating those definitions, so I support
the idea of an uapi header.

> It *is* part of the hypervisor API, but it's not Linux's job to export that and
> deal with the fallout if it was ever changed.

Regardless of what happens if that phyp API changes, KVM would still
need to support those hypercalls, so I think it should export them as well.

Cheers,
Andre.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Paolo Bonzini June 23, 2015, 10:33 a.m. | #6
On 23/06/2015 12:31, Andre Przywara wrote:
>> > 
>> > Because it's not part of the kernel API, never was, still isn't.
> Technically it may not - if I get this correctly it is more a platform
> API defined by the architecture, like ACPI or PSCI on ARM.
> But if I get this correctly Linux re-uses those definitions in the KVM
> API, by piggy-backing on the existing hypercalls. Please correct me if I
> am wrong here, I am looking at arch/powerpc/kvm/book3s_hv.c, where it
> seems to trap those hypercalls.
> 
> So I think that - though not originally invented or defined by Linux -
> it should export those definitions that KVM (re-)uses.
> QEMU also has a header file duplicating those definitions, so I support
> the idea of an uapi header.

Right, the same is true for other headers: include/scsi/scsi.h and
include/uapi/linux/virtio_*.h come to mind.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

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__
-
 #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.