From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Date: Tue, 23 Jun 2015 10:31:43 +0000 Subject: Re: [PATCH 1/2] powerpc: Define the hcall opcodes & return values we need Message-Id: <5589358F.1080606@arm.com> List-Id: References: <1434698461-15539-1-git-send-email-mpe@ellerman.id.au> <558927F5.1040401@redhat.com> <1435053939.20070.2.camel@ellerman.id.au> In-Reply-To: <1435053939.20070.2.camel@ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michael Ellerman , Paolo Bonzini Cc: Will Deacon , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , "svaidy@linux.vnet.ibm.com" , "matt@ozlabs.org" 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 >>> >>> -/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */ >>> -#define __KERNEL__ >>> -#include >>> -#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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [PATCH 1/2] powerpc: Define the hcall opcodes & return values we need Date: Tue, 23 Jun 2015 11:31:43 +0100 Message-ID: <5589358F.1080606@arm.com> References: <1434698461-15539-1-git-send-email-mpe@ellerman.id.au> <558927F5.1040401@redhat.com> <1435053939.20070.2.camel@ellerman.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Will Deacon , "kvm@vger.kernel.org" , "kvm-ppc@vger.kernel.org" , "svaidy@linux.vnet.ibm.com" , "matt@ozlabs.org" To: Michael Ellerman , Paolo Bonzini Return-path: Received: from cam-admin0.cambridge.arm.com ([217.140.96.50]:37254 "EHLO cam-admin0.cambridge.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753906AbbFWKbe (ORCPT ); Tue, 23 Jun 2015 06:31:34 -0400 In-Reply-To: <1435053939.20070.2.camel@ellerman.id.au> Sender: kvm-owner@vger.kernel.org List-ID: 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 >>> >>> -/* We need some of the H_ hcall defs, but they're __KERNEL__ only. */ >>> -#define __KERNEL__ >>> -#include >>> -#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.