qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] target/riscv: change RISCV_EXCP_SEMIHOST exception number to


From: Clément Léger
Subject: Re: [PATCH] target/riscv: change RISCV_EXCP_SEMIHOST exception number to 63
Date: Tue, 23 Apr 2024 14:48:18 +0200
User-agent: Mozilla Thunderbird


On 22/04/2024 21:58, Daniel Henrique Barboza wrote:
> 
> 
> On 4/22/24 16:44, Richard Henderson wrote:
>> On 4/22/24 10:45, Daniel Henrique Barboza wrote:
>>> Palmer, Anup,
>>>
>>> On 4/22/24 10:58, Clément Léger wrote:
>>>> The current semihost exception number (16) is a reserved number (range
>>>> [16-17]). The upcoming double trap specification uses that number for
>>>> the double trap exception. Since the privileged spec (Table 22) defines
>>>> ranges for custom uses change the semihosting exception number to 63
>>>> which belongs to the range [48-63] in order to avoid any future
>>>> collisions with reserved exception.
>>>
>>>
>>> I didn't find any reference to a number for the SEMIHOST exception here:
>>>
>>>
>>> https://github.com/riscv-non-isa/riscv-semihosting
>>>
>>>
>>> Do we have any potential candidates? I would like to avoid, if
>>> possible, setting
>>> RISCV_EXCP_SEMIHOST to 63 as a band-aid just to replace it later on
>>> by the real
>>> value.
>>
>> RISCV_EXCP_SEMIHOST is internal to the qemu implementation and will
>> never be delivered to the guest.
>>
>> I suggest using a number high in the >64 reserved range which will
>> (likely) never be used by any implementation, including ones that *do*
>> define implementation-specific exceptions.  Which seems more likely
>> than not within the "implementation defined" range.
>>
>> E.g. target/i386 uses 0x100+n for qemu internal exceptions.
> 
> I'm not sure if we have a range for risc-v qemu internal exceptions
> only. IIRC we don't.
> 
> If that's really the case I believe we could use whatever i386/ARM uses.
> At least we'll have some
> standardization.

The spec also states that numbers >= 64 are reserved which is why using
a one for custom use was making sense.

Thanks,

Clément

> 
> 
> Thanks,
> 
> Daniel
> 
>>
>> But in any case, the number can be redefined at will and not cause
>> compatibility issues.
>>
>>
>> r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]