Re:[RFC PATCH 0/9] vfio: Introduce mmap maple tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jason Gunthorpe <jgg@xxxxxxxx> writes:

> map2 should not exist, once you introduced a vfio_mmap_ops for free
> then the mmap op should be placed into that structure.

Does this mean dropping mmap op completely from vfio ops? I think we
could update mmap op in vfio to have the vmmap structure, no?

> ioctl2 is nasty, that should be the "new function op for
> VFIO_DEVICE_GET_REGION_INFO" instead. We have been slowly moving
> towards the core code doing more decode and dispatch of ioctls instead
> of duplicating in drivers.

ack.

> I still stand by the patch plan I gave in the above email. Clean up
> how VFIO_DEVICE_GET_REGION_INFO is handled by drivers and a maple tree
> change will trivially drop on top.
>

but I think also prior of migrating to use packed offsets, we would need
to fix the previous offset calculations, which means read & write ops
also need to access the vmmap object to convert the offset.



Another question is: since VFIO_DEVICE_GET_REGION_INFO will use mt and
technically will create and return different cookie offset everytime
it's called for the same region, do we expect that this will not break
any userspace usage?  I'm not sure but could be that some user usage
relying on calling the get_region_info to produce the same offset as the
initial call, instead of caching the region offset for example?

Thanks a lot,
MNAdam



Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597





[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux