iommu hypervisor hypothetical

iommu hypervisor hypothetical

[John Rose]

Suppose the hypervisor added new failure codes for the hcall that does
tce_build().  Suppose that the device driver needed to expect such
failures when alloc_[coherent,consistent] is not successful, and handle
that case accordingly.

Is this something we can accommodate without rewriting the iommu stuff
for various platforms?  All these functions in machdep.h are defined to
return NULL.  Is this because we haven't had a reasonable expectation of
failure, or because device drivers _have_ to assume success for such
operations?

Thanks-
John

Re: iommu hypervisor hypothetical

[Olof Johansson]

On Wed, 27 Sep 2006 11:47:51 -0500 John Rose <johnrose@austin.ibm.com> wrote:

> Suppose the hypervisor added new failure codes for the hcall that does
> tce_build().  Suppose that the device driver needed to expect such
> failures when alloc_[coherent,consistent] is not successful, and handle
> that case accordingly.
> 
> Is this something we can accommodate without rewriting the iommu stuff
> for various platforms?  All these functions in machdep.h are defined to
> return NULL.  Is this because we haven't had a reasonable expectation of
> failure, or because device drivers _have_ to assume success for such
> operations?

iommu_alloc can already fail. So just change the prototype of tce_build
to return success/failure, and handle it accordingly in iommu_alloc
(DMA_ERROR_CODE). The error should move on up the stack from there.

Or did I misunderstand your question in the first place? It's sort of
sparse on details. :-)


-Olof

Re: iommu hypervisor hypothetical

[John Rose]

> So just change the prototype of tce_build
> to return success/failure, and handle it accordingly in iommu_alloc
> (DMA_ERROR_CODE). The error should move on up the stack from there.

I'm thinking of functions like dma_map_single(), which returns the
unsigned type dma_addr_t.  Suppose H_HCE_PUT fails, and this gets
propagated up to the device driver through DMA_ERROR_CODE.  The PAPR
currently defines 2 ways in which this could fail, and we're considering
at least one more.  One error code doesn't seem sufficient.

> Or did I misunderstand your question in the first place? It's sort of
> sparse on details. :-)

You know how it goes :)  I guess my question is whether passing specific
failure conditions up the call chain is permissible/feasible, and
whether the prototypes for the various device driver DMA utilities are
set in stone.

Thanks-
John

Re: iommu hypervisor hypothetical

[Olof Johansson]

On Wed, 27 Sep 2006 13:25:57 -0500 John Rose <johnrose@austin.ibm.com> wrote:

> > So just change the prototype of tce_build
> > to return success/failure, and handle it accordingly in iommu_alloc
> > (DMA_ERROR_CODE). The error should move on up the stack from there.
> 
> I'm thinking of functions like dma_map_single(), which returns the
> unsigned type dma_addr_t.  Suppose H_HCE_PUT fails, and this gets
> propagated up to the device driver through DMA_ERROR_CODE.  The PAPR
> currently defines 2 ways in which this could fail, and we're considering
> at least one more.  One error code doesn't seem sufficient.

So you need to know in the driver why it failed, to take separate
actions based on why? Driver/device events aren't communicated in any
other manner?

> > Or did I misunderstand your question in the first place? It's sort of
> > sparse on details. :-)
> 
> You know how it goes :)  I guess my question is whether passing specific
> failure conditions up the call chain is permissible/feasible, and
> whether the prototypes for the various device driver DMA utilities are
> set in stone.

You could expand to other DMA_ERROR_.* codes, as long as you modify
dma_mapping_error accordingly.


-Olof

Re: iommu hypervisor hypothetical

[Benjamin Herrenschmidt]

On Wed, 2006-09-27 at 13:25 -0500, John Rose wrote:
> > So just change the prototype of tce_build
> > to return success/failure, and handle it accordingly in iommu_alloc
> > (DMA_ERROR_CODE). The error should move on up the stack from there.
> 
> I'm thinking of functions like dma_map_single(), which returns the
> unsigned type dma_addr_t.  Suppose H_HCE_PUT fails, and this gets
> propagated up to the device driver through DMA_ERROR_CODE.  The PAPR
> currently defines 2 ways in which this could fail, and we're considering
> at least one more.  One error code doesn't seem sufficient.

That's a design issue with the linux API that has been around for some
time. At first, there was no possible error return from dma_map_single()
in fact :( DMA_ERROR_CODE was added, and I see no way to do something
better from that function...

> > Or did I misunderstand your question in the first place? It's sort of
> > sparse on details. :-)
> 
> You know how it goes :)  I guess my question is whether passing specific
> failure conditions up the call chain is permissible/feasible, and
> whether the prototypes for the various device driver DMA utilities are
> set in stone.
> 
> Thanks-
> John