On Fri, Oct 09 2020 at 11:52, Jason Gunthorpe wrote:
> On Fri, Oct 09, 2020 at 04:44:27PM +0200, Thomas Gleixner wrote:
>> > This is really not that different from what I was describing for queue
>> > contexts - the queue context needs to be assigned to the irq # before
>> > it can be used in the irq chip other wise there is no idea where to
>> > write the msg to. Just like pasid here.
>>
>> Not really. In the IDXD case the storage is known when the host device
>> and the irq domain is initialized which is not the case for your variant
>> and it neither needs to send a magic command to the device to update the
>> data.
>
> I mean, needing the PASID vs needing the memory address before the IRQ
> can be use are basically the same issue. Data needs to be attached to
> the IRQ before it can be programmed.. In this case programming with
> the wrong PASID could lead to a security issue.
Yeah. I looked at doing it similar to the callback I added for
retrieving the shadow storage pointer, but the PASID is not necessarily
established at that point.
>> I agree that irq_set_auxdata() is not the most elegant thing, but the
>> alternative solutions I looked at are just worse.
>
> It seems reasonable, but quite an obfuscated way to tell a driver they
> need to hold irq_get_desc_buslock() when touching data shared with the
> irqchip ops.. Not that I have a better suggestion
It's an obfuscated way to make obfuscated hardware supported :)
Thanks,
tglx
