qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH qemu 1/3] memory: Add get_fd() hook for IOMM


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC PATCH qemu 1/3] memory: Add get_fd() hook for IOMMU MR
Date: Wed, 29 Mar 2017 10:04:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0


On 29/03/2017 05:04, Alex Williamson wrote:
>>> What if we used this as a prototype:
>>>
>>> int (*get_fd)(IOMMUFdType type, MemoryRegion *iommu);
>>>
>>> And then we defined:
>>>
>>> typedef enum {
>>>     SPAPR_IOMMU_TABLE_FD = 0,
>>> } IOMMUFdType;  
>>
>> Where do I put this enum definition? include/exec/memory.h? It does not
>> have any mention of any platform yet...
>  
> I would assume memory.h, yes.  It seems like the enum is just an
> abstraction, what does "get fd" mean generically to an IOMMU
> MemoryRegion?  How can anyone else ever implement that callback if the
> initial user is assuming that the returned fd is a specific, yet
> unspecified type.  If the API is "give me an fd for this type of thing"
> then the IOMMU driver can either provide it or indicate that type is not
> supported.  There's really no platform knowledge at the memory API
> level, it's just a type of thing that means something to the driver
> providing the MemoryRegionIOMMUOps and the caller.

I think we should move to a QOM hierarchy like

   AbstractMemoryRegion
      MemoryRegion                  << adds MemoryRegionOps
      IOMMUMemoryRegion             << adds MemoryRegionIOMMUOps
        sPAPR_IOMMUMemoryRegion     << adds get_fd

but for now I'm okay with Alex's proposal.

Paolo



reply via email to

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