Nicholas Piggin <npig...@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
