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" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
