Messages in this thread | | | Date | Fri, 27 Jan 2012 15:22:43 -0600 | From | Scott Wood <> | Subject | Re: [PATCH 2/5] iommu/amd: Implement DOMAIN_ATTR_GEOMETRY attribute |
| |
On 01/27/2012 05:01 AM, Joerg Roedel wrote: > On Thu, Jan 26, 2012 at 02:02:26PM -0600, Scott Wood wrote: >> On 01/26/2012 01:44 PM, Joerg Roedel wrote: > >>>>> Another reason why it must be in the generic struct is the intended >>>>> generic dma-ops layer on-top. This code can decide on this flag wheter a >>>>> address needs to be remapped at all. >>>> >>>> So the DMA API would just read this, not write it? > > Yes, the dma-ops code needs this information to decide whether remapping > is required at all and where the remap window is. > >>> The whole geometry thing is only implemented on the read side. There is >>> no implementation in domain_set_attr for it. So the geometry >>> information is read-only by default. >> >> We will need to be able to set this, for some vfio+kvm uses. > > That's fine. Just implement a handler for it in the driver-specific > set_attr callback then.
OK, so there's a geometry that is read-only, and potentially a driver-specific geometry that is read/write. The default config for PAMU would likely be a 1 MiB aperture in which the dma api can do arbitrary 4k mappings -- this fits within the get generic geometry operation.
Should generic get geometry return an error if the driver-specific geometry has been set to something that doesn't fit within the generic geometry model?
>>>> Still no reason why it couldn't be a separate attribute. Then if you >>>> get a failure trying to write it, it's more obvious why. >>> >>> This would mean iommu specific hacks, which are not necessary in this >>> case. >> >> Why would making it a separate generic attribute require iommu specific >> hacks? > > Because the dma-ops code needs something like > > iommu_domain_get_attr(domain, GART_ATTR_FORCE_APERTURE, data); > > to check it. I call this a hack because the dma-ops code asks if it runs > on a specific hardware. This is not necessary here.
I said a generic attribute (not GART specific) -- but if we're never going to use the generic geometry struct for a set operation, bundling it should be OK.
>>> Which hardware capabilities besides the geometry do you mean? >> >> Well, we have things like stash target (automatic cache prefetch after >> DMA) configuration, but in this case I was thinking about restrictions >> on what kind of aperture you can set, and what sort of mappings you can >> create with the result. > > The stash target is a perfect fit for a PAMU specific domain attribute.
Yes.
> Yes, we talked about that already. Probably we should talk about code to > make progress here. Do you have anything ready to post?
No, at this point I'm just trying to follow the API development while tending to other tasks. I think Varun is working on the code for now.
-Scott
| |