Re: [PATCH v1 0/3] vpci/msix: separate out common MSI-X code

[Jan Beulich <jbeulich@suse.com>]

On 28.10.2026 09:43, Mykyta Poturai wrote:
> On 10/27/26 12:21 PM, Jan Beulich wrote:
>> On 27.10.2026 10:39, Mykyta Poturai wrote:
>>> On 10/26/26 2:34 PM, Jan Beulich wrote:
>>>> On 26.10.2026 13:27, Mykyta Poturai wrote:
>>>>> This is preparatory work to make vPCI MSI-X functional on Arm. Split the
>>>>> vPCI MSI-X code so that intercepting the MSI-X table and PBA stays x86
>>>>> only,
>>>>
>>>> This likely is related to peculiarities of Arm's interrupt handling, yet
>>>> on the surface I can't see why not intercepting MSI-X table accesses
>>>> would be safe. Would it be possible to extend background here a little?
>>>
>>> On Arm most of the work is done by the ITS, so the only thing the device
>>> needs to write to the doorbell register is the EventID. Interrupt
>>> translation is fully configured in the ITS; it will reject invalid
>>> EventIDs and also has a sideband DeviceID, so misconfigured devices
>>> cannot trigger each other's interrupts. Memory-wise everything is gated
>>> by the IOMMU, so a wrong doorbell address would not pose any risk either.
>>
>> And a guest fiddling with the mask bits behind Xen's back isn't a problem
>> either?
> 
> No. Masking/unmasking an interrupt the guest has already mapped is just 
> the guest doing its own configuration. Unmasking an unmapped interrupt 
> will result in it being discarded by the ITS. So I don't see a problem 
> here either.

IOW unlike on x86, on Arm Xen never has a need to (transiently) mask an
interrupt that the guest wants / considers unmasked?

Jan