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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan