Re: Programming PASID in IMS entries

From: Thomas Gleixner
Date: Wed Jul 07 2021 - 04:50:55 EST


On Wed, Jul 07 2021 at 09:49, Megha Dey wrote:
> Per your suggestions during the last meeting, we wanted to confirm the
> sequence to program the PASID into the IMS entries:
> 1. Add a PASID member to struct msi_desc (Add as part of a union. Other
> source-id's such as Jason's vm-id can be added to it)

Yes. Though we also discussed storing the default PASID in struct device
to begin with which is then copied to the msi_desc entries during

> 2. Create an API which device drivers can call, to program the PASID
> (PASID provided by the driver) on a per-irq basis. This API is to be
> called after msi_domain_alloc_irqs and will write to the corresponding
> msi_desc->pasid entry. (Assumption: For now, all devices will have the
> same IMS format). for e.g:
> msi_desc_set_pasid (irq, pasid) {
> struct msi_desc *desc = irq_get_msi_desc(irq);
> desc->pasid = pasid;
> }

That interface should be opaque probably with an u64 argument so it can
be reused for Jason's VM-id. Jason?

> 3. In request_irq, add a irq_chip callback (in __setup_irq maybe??) to
> automatically write the pasid into the corresponding IMS entry:

Why? There is no need for yet another callback. The PASID or whatever ID
is required can be written as part of e.g. irq_unmask().

> Is this the correct approach?


> Also, from a previous discussion [1], we want to make IMS more dynamic:
> Given the QEMU behavior it doesn't ask for all IRQs upfront. It only
> allocates 1, and when it unmasks the 2nd, it wants to dynamically add a
> second. This will allow adding a second IRQ without having to free all
> the old irqs and reacquire the new number (as it is done today).
> This dynamic behavior is only for MSIx/IMS backed entries. For legacy
> MSI, QEMU will allocate everything upfront. Since it has a
> "num_vectors" enabled, nothing can be dynamically done for MSI. Kevin
> is looking to have this fixed for legacy to stop the dynamic part for
> MSI. We are pursuing this change just for IMS first, and once it
> works, we can replicate the same for MSIx too.

No. Fix the existing stuff first and then IMS just works.

> In order to make IMS dynamic, we were thinking of the following
> enhancements to the IMS core:
> 1. Device Driver specifies maximum number of interrupts the sub device
> is allowed to request, while creating the dev-msi domain. E.g. in the
> case of DSA, Driver can specify that each mdev created can have upto X

Why would this be mdev specific? IIRC the sub devices can be used on
bare metal as well.

> number of IMS interrupts. If device asks for more than this number,it
> will behave like how current IRQ allocation works i.e. give what is
> available.
> 2. Driver can ask for more interrupts after probe as well as long as the
> request has not exceeded the maximum permitted for it and the physical
> device has the requested number available.


> We are still working on the virtualization flows: when guest updates
> PASID, and how it flows to host IMS update. But we will come to that
> once the above pieces are agreed upon.