qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH][RFC] IOMMU: Add Support to VFIO devices with vI


From: Aviv B.D.
Subject: Re: [Qemu-devel] [PATCH][RFC] IOMMU: Add Support to VFIO devices with vIOMMU present
Date: Sat, 19 Mar 2016 11:40:04 +0200



On Fri, Mar 18, 2016 at 5:06 AM, Peter Xu <address@hidden> wrote:
On Thu, Mar 17, 2016 at 01:17:30PM +0200, Aviv B.D. wrote:
[...]
> vtd_get_did_dev returns -1 if the device is not mapped to any domain
> (generally, the CE is not present).
> probably a better interface is to return whether the device has a domain or
> not and returns the domain_id via the pointer argument.

Possibly, as long as guest kernel might be using (uint16_t)-1 as
domain ID. ;)

>
>
> >
> > > >+                domain_id == vfio_domain_id){
> > > >+            VTDIOTLBEntry *iotlb_entry = vtd_lookup_iotlb(s,
> > vfio_source_id, addr);
> > > >+            if (iotlb_entry != NULL){
> >
> > Here, shall we notify VFIO even if the address is not cached in
> > IOTLB? Anyway, we need to do the unmap() of the address, am I
> > correct?
> >
> With this code I do a unmap operation if the address was cached in the
> IOTLB, if not I'm assuming that the current invalidation invalidate an
> (previously) non present address and I should do a map operation (during
> the map operation I'm calling s->iommu_ops.translate that caches the
> address).

I am not 100% sure of this, but... is this related to IOTLB at all?
What I see is that, IOTLB is only a cache layer of IOMMU, and it is
possible that we mapped some areas which are not in the IOTLB at
all.

Or, let's make an assumption here: what if I turn IOTLB off (or say,
set hash size to zero)? IOMMU should still work, though slower,
right?  However, due to above checking, we'll never do ummap() in
this case (while IMHO we should). 
Thanks.

-- peterx


Hi,
As far as I understand the code, currently there is no way to turn off the IOTLB. 
Furthermore. the IOTLB is not implemented as LRU, and actually caches (indefinitely)  
any accessed address, without any size constrains. I use those assumptions to know
whether the current invalidation is for unmap operation or map operation. 

But, I need to check if it possible (for the guest kernel) to squeeze together unmap and 
map operations and issue for them only one invalidation (probably the answer is yes, 
and it may explain one of my bugs)
 
Aviv.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]