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
