On 22-06-22, 18:05, Oleksandr Tyshchenko wrote:
Even leaving aside the fact that restricted virtio memory access in the guest means that not all of guest memory can be accessed, so even having pre-maped guest memory in advance, we are not able to calculate a host pointer as we don't know which gpa the particular grant belongs to.
Ahh, I clearly missed that as well. We can't simply convert the address here on the requests :(
I am not sure that I understand this use-case. Well, let's consider the virtio-disk example, it demonstrates three possible memory mapping modes:
- All addresses are gpa, map/unmap at runtime using foreign mappings
- All addresses are gpa, map in advance using foreign mappings
- All addresses are grants, only map/unmap at runtime using grants mappings
If you are asking about #4 which would imply map in advance together with using grants then I think, no. This won't work with the current stuff. These are conflicting opinions, either grants and map at runtime or gpa and map in advance. If there is a wish to optimize when using grants then "maybe" it is worth looking into how persistent grants work for PV block device for example (feature-persistent in blkif.h).
I though #4 may make it work for our setup, but it isn't what we need necessarily.
The deal is that we want hypervisor agnostic backends, they won't and shouldn't know what hypervisor they are running against. So ideally, no special handling.
To make it work, the simplest of the solutions can be to map all that we need in advance, when the vhost negotiations happen and memory regions are passed to the backend. It doesn't necessarily mean mapping entire guest, but just the regions we need.
With what I have understood about grants until now, I don't think it will work straight away.
Yes, this is the correct environment. Please note that Juergen has recently pushed new version [1]
Yeah, I am following them up, will test the one you all agree on :)
Thanks.