iommu hypervisor hypothetical

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

On Wed, 27 Sep 2006 11:47:51 -0500 John Rose [off-list ref] 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

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

On Wed, 27 Sep 2006 13:25:57 -0500 John Rose [off-list ref] wrote:

quoted

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?

quoted

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

On Wed, 2006-09-27 at 13:25 -0500, John Rose wrote:

quoted

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...

quoted

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