On Wed, Jul 05, 2023 at 03:16:31PM +0200, Eric Auger wrote:
> >>> diff --git a/hw/virtio/virtio-iommu.c b/hw/virtio/virtio-iommu.c index
> >>> 1eaf81bab5..0d9f7196fe 100644
> >>> --- a/hw/virtio/virtio-iommu.c
> >>> +++ b/hw/virtio/virtio-iommu.c
> >>> @@ -1101,29 +1101,24 @@ static int
> >>> virtio_iommu_set_page_size_mask(IOMMUMemoryRegion *mr,
> >>> new_mask);
> >>>
> >>> if ((cur_mask & new_mask) == 0) {
> >>> - error_setg(errp, "virtio-iommu page mask 0x%"PRIx64
> >>> - " is incompatible with mask 0x%"PRIx64, cur_mask,
> >>> new_mask);
> >>> + error_setg(errp, "virtio-iommu %s reports a page size mask
> >>> 0x%"PRIx64
> >>> + " incompatible with currently supported mask
> >>> 0x%"PRIx64,
> >>> + mr->parent_obj.name, new_mask, cur_mask);
> >>> return -1;
> >>> }
> >>>
> >>> /*
> >>> * Once the granule is frozen we can't change the mask anymore. If by
> >>> * chance the hotplugged device supports the same granule, we can
> >>> still
> >>> - * accept it. Having a different masks is possible but the guest
> >>> will use
> >>> - * sub-optimal block sizes, so warn about it.
> >>> + * accept it.
> >>> */
> >>> if (s->granule_frozen) {
> >>> - int new_granule = ctz64(new_mask);
> >>> int cur_granule = ctz64(cur_mask);
> >>>
> >>> - if (new_granule != cur_granule) {
> >>> - error_setg(errp, "virtio-iommu page mask 0x%"PRIx64
> >>> - " is incompatible with mask 0x%"PRIx64, cur_mask,
> >>> - new_mask);
> >>> + if (!(BIT(cur_granule) & new_mask)) {
> > Sorry, I read this piece code again and got a question, if new_mask has
> > finer
> > granularity than cur_granule, should we allow it to pass even though
> > BIT(cur_granule) is not set?
> I think this should work but this is not straightforward to test.
> virtio-iommu would use the current granule for map/unmap. In map/unmap
> notifiers, this is split into pow2 ranges and cascaded to VFIO through
> vfio_dma_map/unmap. The iova and size are aligned with the smaller
> supported granule.
>
> Jean, do you share this understanding or do I miss something.
Yes, I also think that would work. The guest would only issue mappings
with the larger granularity, which can be applied by VFIO with a finer
granule. However I doubt we're going to encounter this case, because
seeing a cur_granule larger than 4k here means that a VFIO device has
already been assigned with a large granule like 64k, and we're trying to
add a new device with 4k. This indicates two HW IOMMUs supporting
different granules in the same system, which seems unlikely.
Hopefully by the time we actually need this (if ever) we will support
per-endpoint probe properties, which allow informing the guest about
different hardware properties instead of relying on one global property in
the virtio config.
Thanks,
Jean
