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

[Nicholas Piggin]

Excerpts from Fabiano Rosas's message of May 4, 2022 1:50 am:
> 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.

Yeah I think I agree, and semihosting code that is intended to compile
away or be dynamically disableable can implement that itself if
needed.

> 
>> - 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.

I don't see downsides actually. A userspace can already induce some HV
interrupts.

So we can use any unallocated opcode, and in the specification we can 
say processors which do not support the semihosting facility
should treat it as an illegal instruction. That means the spec is 
backward compatible. It also gives you the trap to HV with HEAI 
interrupt on existing processors so KVM can implement it for guests.

Maybe it's as simple as that?

> 
>> - 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.

Okay.

Thanks,
Nick