Re: [PATCH v1 07/15] xen/riscv: introduce tracking of pending vCPU interrupts, part 1

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.01.2026 12:46, Oleksii Kurochko wrote:
> 
> On 1/15/26 11:59 AM, Jan Beulich wrote:
>> On 15.01.2026 11:55, Oleksii Kurochko wrote:
>>> On 1/15/26 10:52 AM, Jan Beulich wrote:
>>>> On 15.01.2026 10:14, Oleksii Kurochko wrote:
>>>>> On 1/14/26 4:56 PM, Jan Beulich wrote:
>>>>>> On 14.01.2026 16:39, Oleksii Kurochko wrote:
>>>>>>> If a guest will do "That (the 1 -> 0 transitions) could be (guest) 
>>>>>>> writes
>>>>>>> to SVIP, for example." then the correspondent HVIP (and HIP as usually
>>>>>>> they are aliasis of HVIP) bits will be updated. And that is why we need
>>>>>>> vcpu_sync_interrupts() I've mentioned in one of replies and sync VSSIP:
>>>>>>> +void vcpu_sync_interrupts(struct vcpu *v)
>>>>>>> +{
>>>>>>> +    unsigned long hvip;
>>>>>>> +
>>>>>>> +    /* Read current HVIP and VSIE CSRs */
>>>>>>> +    v->arch.vsie = csr_read(CSR_VSIE);
>>>>>>> +
>>>>>>> +    /* Sync-up HVIP.VSSIP bit changes does by Guest */
>>>>>>> +    hvip = csr_read(CSR_HVIP);
>>>>>>> +    if ( (v->arch.hvip ^ hvip) & BIT(IRQ_VS_SOFT, UL) )
>>>>>>> +    {
>>>>>>> +        if ( hvip & BIT(IRQ_VS_SOFT, UL) )
>>>>>>> +        {
>>>>>>> +            if ( !test_and_set_bit(IRQ_VS_SOFT,
>>>>>>> +                                   &v->arch.irqs_pending_mask) )
>>>>>>> +                set_bit(IRQ_VS_SOFT, &v->arch.irqs_pending);
>>>>>>> +        }
>>>>>>> +        else
>>>>>>> +        {
>>>>>>> +            if ( !test_and_set_bit(IRQ_VS_SOFT,
>>>>>>> +                                   &v->arch.irqs_pending_mask) )
>>>>>>> +                clear_bit(IRQ_VS_SOFT, &v->arch.irqs_pending);
>>>>>>> +        }
>>>>>>> +    }
>>>>>> I fear I don't understand this at all. Why would the guest having set a
>>>>>> pending bit not result in the IRQ to be marked pending?
>>>>> Maybe it is wrong assumption but based on the spec:
>>>>>      Bits sip.SSIP and sie.SSIE are the interrupt-pending and 
>>>>> interrupt-enable
>>>>>      bits  for supervisor-level software interrupts. If implemented, SSIP 
>>>>> is
>>>>>      writable in sip and may also be set to 1 by a platform-specific 
>>>>> interrupt
>>>>>      controller.
>>>>> and:
>>>>>      Interprocessor interrupts are sent to other harts by 
>>>>> implementation-specific
>>>>>      means, which will ultimately cause the SSIP bit to be set in the 
>>>>> recipient
>>>>>      hart’s sip register.
>>>>>
>>>>> Meaning that sending an IPI to self by writing 1 to sip.SSIP is
>>>>> well-defined. The same should be true of vsip.SSIP while in VS mode.
>>>> I can't read that out of the text above. To the contrary, "will ultimately 
>>>> cause
>>>> the SSIP bit to be set" suggests to me that the bit is not to be set by 
>>>> writing
>>>> the CSR. Things still may work like this for self-IPI, but that wouldn't 
>>>> follow
>>>> from the quotation above.
>>> Why not that wouldn't follow from the quotation above?
>>>
>>> The first quotation tells that we can do self-IPI so VSSIP.SSIP will set to 
>>> 1
>>> what we could miss SSIP bit if won't explicitly try to read h/w HVIP (or 
>>> VSSIP,
>>> or whatever other alias of the SSIP bit) and sync with what we have cached
>>> in hypervisor.
>> The bit being writable doesn't imply that it being written with 1 would also
>> trigger an interruption. If that's indeed the behavior, it surely is being
>> said elsewhere.
> 
> According to the spec it will trap to S-mode (VS-mode in our context) if both 
> of
> the following are true: (a) either the current privilege mode is S and the SIE
> bit in the sstatus register is set, or the current privilege mode has less
> privilege than S-mode; and (b) bit i is set in both sip and sie.

That's still not it. Here is the relevant quote:

"These conditions for an interrupt trap to occur must be evaluated in a bounded
 amount of time from when an interrupt becomes, or ceases to be, pending in sip,
 and must also be evaluated immediately following the execution of an SRET
 instruction or an explicit write to a CSR on which these interrupt trap
 conditions expressly depend (including sip, sie and sstatus)."

Note in particular the "explicit write to a CSR". (Sorry, I did read that 
before,
but I didn't memorize it. Else I wouldn't have asked the original question.)

Jan