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

[Andre Przywara <andre.przywara@arm.com>]

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.