On Tue, Mar 8, 2022 at 11:48 AM Michael S. Tsirkin <mst@redhat.com> wrote:
On Tue, Mar 08, 2022 at 04:20:53PM +0800, Jason Wang wrote:
Not by itself but I'm not sure we can guarantee guest will not
attempt to use the IOVA addresses we are reserving down
the road.
The IOVA is allocated via the listeners and stored in the iova tree
per GPA range as IOVA->(GPA)->HVA.Guests will only see GPA, Qemu
virtio core see GPA to HVA mapping. And we do a reverse lookup to find
the HVA->IOVA we allocated previously. So we have double check here:
1) Qemu memory core to make sure the GPA that guest uses is valid
2) the IOVA tree that guarantees there will be no HVA beyond what
guest can see is used
So technically, there's no way for the guest to use the IOVA address
allocated for the shadow virtqueue.
Thanks
I mean, IOVA is programmed in the host hardware to translate to HPA, right?
Yes, that's right if the device uses physical maps. Also to note, SVQ
vring is allocated in multiples of host huge pages to avoid garbage or
unintended access from the device.
If a vdpa device uses physical addresses, kernel vdpa will pin qemu
memory first and then will send IOVA to HPA translation to hardware.
But this IOVA space is not controlled by the guest, but by SVQ. If a
guest's virtqueue buffer cannot be translated first to GPA, it will
not be forwarded.
Thanks!