Virtualization - Mar 2022 - [PATCH v5 00/15] vDPA shadow virtqueue

? 2022/3/8 ??8:16, Michael S. Tsirkin ??:
> On Tue, Mar 08, 2022 at 12:37:33PM +0100, Eugenio Perez Martin wrote:
>> On Tue, Mar 8, 2022 at 11:48 AM Michael S. Tsirkin <mst at
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!
> Right. So if guests send a buffer where buffer address overlaps the
> range we used for the SVQ, then I think at the moment guest won't work.

There's no way for a guest to do this, it can only use GPA but the Qemu 
won't let vDPA to use GPA as IOVA. Dedicated IOVA ranges were allocated 
for those GPA ranges so SVQ won't use IOVA that is overlapped with what 
Guest use.

Thanks

>

On Wed, Mar 09, 2022 at 11:38:35AM +0800, Jason Wang
wrote:
> 
> ? 2022/3/8 ??8:16, Michael S. Tsirkin ??:
> > On Tue, Mar 08, 2022 at 12:37:33PM +0100, Eugenio Perez Martin wrote:
> > > On Tue, Mar 8, 2022 at 11:48 AM Michael S. Tsirkin <mst at
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!
> > Right. So if guests send a buffer where buffer address overlaps the
> > range we used for the SVQ, then I think at the moment guest won't
work.
> 
> 
> There's no way for a guest to do this, it can only use GPA
With a vIOMMU it can.
> but the Qemu
> won't let vDPA to use GPA as IOVA. Dedicated IOVA ranges were allocated
for
> those GPA ranges so SVQ won't use IOVA that is overlapped with what
Guest
> use.
> 
> Thanks
> 
> 
> >