[virtio-dev] Re: [PATCH v1 2/2] virtio-mmio: add features for virtio-mmio specification version 3

["Liu, Jing2" <jing2.liu@linux.intel.com>]

On 1/5/2020 7:04 PM, Michael S. Tsirkin wrote:
> [...]
>> +static int vm_find_vqs_msi(struct virtio_device *vdev, unsigned int nvqs,
>> +			struct virtqueue *vqs[], vq_callback_t *callbacks[],
>> +			const char * const names[], const bool *ctx,
>> +			struct irq_affinity *desc)
>> +{
>> +	int i, err, irq;
>> +	struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
>> +
>> +	/* Allocate nvqs irqs for queues and one irq for configuration */
>> +	err = vm_request_msi_vectors(vdev, nvqs + 1);
>> +	if (err != 0)
>> +		return err;
> Not all devices need high speed.  Some might want to share
> irqs between VQs, or even with config change callback.
> Balloon is a case in point.
> A hint about max # of MSI necessary would be a good
> idea for this case.

This seems being a hint about telling MSI number device supported and 
whether it wants MSI sharing.

For devices with tens of queues at most or need high speed, they choose 
vector per queue, and can simply use fixed mapping.

For others, it can ask for advanced mode, which means MSI sharing and 
dynamic mapping.

What about let device decide the mode it would use, as follows.

MaxVecNum 32bit - The max msi vector number that device supports.

MsiState 32bit

- bit[x]=0 implies vec per queue/config and fixed mapping. In this case, 
MsiVecNum>=num_queue+1

- bit [x]=1 implies the hint of msi sharing and dynamic mapping. In this 
case, MsiVecNum<num_queue+1


Thanks,

Jing

>
> Sharing MSI doesn't necessarily require dedicated registers like PCI has,
> you can just program same vector in multiple VQs.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org