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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.01.2026 13:25, Oleksii Kurochko wrote:
> 
> On 1/15/26 1:09 PM, Jan Beulich wrote:
>> 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.)
> 
> Guest can do:
>    csr_write(CSR_SIP, SSIP);
> what is an explicit write to a CSR. Or it the quote it means a different CSR?

That's what is meant, aiui.

Jan