| Message ID | 1434698461-15539-1-git-send-email-mpe@ellerman.id.au |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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
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
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
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
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
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
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.
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(-)