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. > All the IDXD driver has to do is: > > auxval = ims_ctrl_pasid_aux(pasid, enabled); > irq_set_auxdata(irqnr, IMS_AUXDATA_CONTROL_WORD, auxval); > > 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 Jason
