On 2020/11/26 下午9:57, Michael S. Tsirkin wrote:
On Thu, Nov 26, 2020 at 05:25:52PM +0800, Jason Wang wrote:
This patch tries to convert the modern device to use devres to manage
its resources (iomaps). Before this patch the IO address is mapped
individually according to the capability. After this patch, we simply
map the whole BAR.
I think the point of mapping capability was e.g. for devices with
huge BARs. We don't want to waste virtual memory for e.g. 32 bit guests.
And in particular the spec says:
The drivers SHOULD only map part of configuration structure large enough for device operation. The drivers
MUST handle an unexpectedly large length, but MAY check that length is large enough for device operation.
Good point, so I will stick to devres but not use the shortcut like
whole BAR mapping.
I also wonder how would this interact with cases where device memory is
mapped for different reasons, such as for MSI table access, into userspace
as it has resources such as virtio mem, etc.
I think it depends on the driver, e.g for virtio-pci and vDPA, the upper
layer driver (virtio bus or vDPA bus) know nothing about transport
specific thing. It should be ok.
E.g. don't e.g. intel CPUs disallow mapping the same address twice
with different attributes?
Do you mean it doesn't allow one VA is mapped as UC but the other is
not? I don't know. But anyhow my understanding is that
virtio-pci/vp_vdpa tries to hide the details so we can not have two
mappings here.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
