Re: [RFC PATCH v3 1/5] ppc64: Add semihosting support

[Fabiano Rosas <farosas@linux.ibm.com>]

Nicholas Piggin <npiggin@gmail.com> writes:

> Excerpts from Nicholas Piggin's message of April 21, 2022 12:04 pm:
>> Excerpts from Leandro Lupori's message of April 21, 2022 4:09 am:
>>> On 4/18/22 17:22, Cédric Le Goater wrote:
>>>> On 4/18/22 21:10, Leandro Lupori wrote:
>>>>> Add semihosting support for PPC64. This implementation is
>>>>> based on the standard for ARM semihosting version 2.0, as
>>>>> implemented by QEMU and documented in
>>>>>
>>>>>      https://github.com/ARM-software/abi-aa/releases
>>>>>
>>>>> The PPC64 specific differences are the following:
>>>>>
>>>>> Semihosting Trap Instruction: sc 7
>>>>> Operation Number Register: r3
>>>>> Parameter Register: r4
>>>>> Return Register: r3
>>>>> Data block field size: 64 bits
>>>> 
>>>> 'sc' is a good way to implement semi hosting but we should make sure
>>>> that it is not colliding with future extensions, at least with the
>>>> next POWERPC processor. Is that the case ? if not, then the lev could
>>>> be reserved.
>>>> 
>>> 
>>> Power ISA 3.1B says that LEV values greater that 2 are reserved.
>>> Level 2 is the ultravisor, so I assumed that level 7 was far enough from 
>>> current max level. I don't know if POWER11 will introduce new privilege 
>>> levels. Is this info publicly available somewhere? Or do you have a 
>>> better level in mind to use instead?
>> 
>> It's not available but there are no plans to use LEV=7.
>> 
>> It would be fine in practice I think, but it's kind of ugly and not 
>> great precedent -- how would we find out all the projects which use 
>> reserved instructions or values for something? Nominally the onus is on 
>> the software to accept breakage, but in reality important software that
>> breaks causes a headache for the ISA.
>> 
>> IBM's systemsim emulator actually has an instruction to call out to the 
>> emulator to do various things like IO. It uses the opcode
>> 
>>   .long 0x000eaeb0
>> 
>> That is the primary op 0 reserved space, and there is actually another 
>> op 'attn' or 'sp_attn' there which IBM CPUs implement, it is similar in 
>> spirit (it calls out to the service processor and/or chip error handling 
>> system to deal with a condition out-of-band). You don't want to use attn 
>> here because the core under emulation might implement it, I'm just 
>> noting the precedent with similar functionality under this primary 
>> opcode.
>> 
>> So I think the systemsim emulator instruction should be a good choice. 
>> But it should really be documented. I will bring this up at the Open 
>> Power ISA working group meeting next week and see what the options are 
>> with getting it formally allocated for semihosting emulators (or what 
>> the alternatives are).
>
> Update on the ISA TWG meeting
>
> Semihosting was well received, the idea is not so new so I think it was
> easily understood by attendees.
>
> There were no objections to allocating a new opcode for this purpose.
> The preference was a new opcode rather than using a reserved sc LEV
> value.
>
> The primary opcode 0 space is possibly unsuitable because it is said
> to be "allocated to specific purposes that are outside the scope of the
> Power ISA." whereas I think we want a first class instruction for this,
> it may have implementation-dependent behaviour but on processors that
> do not implement it, we would like it to have well-defined behaviour.
>
> So we can probably just pick an opcode and submit a patch RFC to the
> ISA (I can try help with that). First, there are a few questions to
> resolve:
>
> - What behaviour do we want for CPUs which do not implement it or
>   disable it? E.g., no-op or illegal instruction interrupt. Ideally
>   we would choose an opcode such that the architecture is compatible
>   with existing CPUs.

I think that since semihosting is not a one-shot thing it would be
better to have it trap so that the "host" could remediate in some
way. Or even carry on with servicing the semihosting anyway.

> - Would it be useful for KVM to implement semihosting support for
>   guests on hard processors?

Are there any undesirable implications to using an instruction that
traps to the HV? I'd say let's get it if we can but otherwise it's not a
big deal.

I had two use-cases in mind:

1) Improving our interactions with gdbstub and having the guest use
   sys_exit to report some debugging events like watchpoints or
   singlestep;

2) Bootstrapping with KVM. We had instances in the past of needing to
   write guest code from scratch and having to rely solely in GDB for a
   while before setting up the console.

But I realise that these use-cases conflate semihosting with general
debugging and regular PAPR features, respectively. So it might be a
stretch.

> - Is there value in an endian-agnostic instruction? (Assuming we can
>   find one). This question only comes to me because our BMC gdbserver
>   for debugging the host CPUs implements breakpoints by inserting an
>   'attn' instruction in the host code, and that does not work if the
>   host switches endian. Any possibility the semihosting instruction
>   would ever be injected out-of-band? Seems not so likely.

Semihosting requires some sort of register setup, I don't think having
it done out-of-band would be practical. So we possibly don't need an
endian-agnostic instruction.

> There were also some thoughts about bringing the semihosting spec
> under the Open Power group but that's outside the scope of the ISA
> group. This may be a possibility we could consider but I think for
> now it should be enough to document it like riscv and put it
> somewhere (even in the QEMU tree should be okay for now IMO).
>
> Thanks,
> Nick