On Thu, May 15, 2008 at 11:03:40PM +0200, Andi Kleen wrote:
> On Thu, May 15, 2008 at 06:26:31PM +0300, Muli Ben-Yehuda wrote:
> > On Thu, May 15, 2008 at 06:41:26PM +0900, FUJITA Tomonori wrote:
> >
> > > I thought that KVM people want to do it per device (in the first
> > > case). So with my patchse, they can replace the dma_ops pointer
> > > in dev_archdata with what they want.
> >
> > That's my understanding too. We use stackable ops as a poor man's
> > replacement for per-device ops (depending on what kind of device
> > it is, call the original ops or our pvdma ops).
>
> But in the KVM case you still need to support the underlying ops
> too, e.g. in case of bouncing through swiotlb needed

Good point, although "secondary" DMA-ops should only be needed in rare
cases (the only one I can think of is bouncing through swiotlb for a
pass-through device which has a limited DMA mask), whereas per-device
ops are needed for every pass-through device.

Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, May 15, 2008 at 11:45:10PM +0200, Andi Kleen wrote:

> Even rare cases need to be handled.

Sure, but I'd rather we handle the common case first.

> In the nodma bitmap case it was the same always btw.

Not sure what you mean?

Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Muli Ben-Yehuda wrote:
> On Thu, May 15, 2008 at 11:03:40PM +0200, Andi Kleen wrote:
>> On Thu, May 15, 2008 at 06:26:31PM +0300, Muli Ben-Yehuda wrote:
>>> On Thu, May 15, 2008 at 06:41:26PM +0900, FUJITA Tomonori wrote:
>>>
>>>> I thought that KVM people want to do it per device (in the first
>>>> case). So with my patchse, they can replace the dma_ops pointer
>>>> in dev_archdata with what they want.
>>> That's my understanding too. We use stackable ops as a poor man's
>>> replacement for per-device ops (depending on what kind of device
>>> it is, call the original ops or our pvdma ops).
>> But in the KVM case you still need to support the underlying ops
>> too, e.g. in case of bouncing through swiotlb needed
>
> Good point, although "secondary" DMA-ops should only be needed in rare
> cases

Even rare cases need to be handled. In the nodma bitmap case it was the
same always btw

-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, May 16, 2008 at 12:53:15AM +0300, Muli Ben-Yehuda wrote:
> On Thu, May 15, 2008 at 11:45:10PM +0200, Andi Kleen wrote:
>
> > Even rare cases need to be handled.
>
> Sure, but I'd rather we handle the common case first.

.... which is not to say of course we can't do both, dev_archdata could
have a list of struct dma_mapping_ops instead of (or in addition to) a
struct dma_mapping_ops pointer. If space was at a premium we could
even multiplex both on the same pointer by using one of the low bits
to select between them.

Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Thu, 15 May 2008 12:48:04 +0200
Andi Kleen wrote:

>
> > I thought that KVM people want to do it per device (in the first
> > case). So with my patchse, they can replace the dma_ops pointer in
> > dev_archdata with what they want.
>
> But where would they save the original pointer?

Yeah, we need an extra mechanism for that but it's same for the
system-wide dma_ops pointer (i.e. without my patches), isn't it?

I'm still not sure how this patchset make it impossible to have stack
dma_ops. These people need per-device dma_ops and we can do stack
per-device dma_ops?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

FUJITA Tomonori wrote:
> On Thu, 15 May 2008 12:48:04 +0200
> Andi Kleen wrote:
>
>>> I thought that KVM people want to do it per device (in the first
>>> case). So with my patchse, they can replace the dma_ops pointer in
>>> dev_archdata with what they want.
>> But where would they save the original pointer?
>
> Yeah, we need an extra mechanism for that but it's same for the
> system-wide dma_ops pointer (i.e. without my patches), isn't it?
>
> I'm still not sure how this patchset make it impossible to have stack
> dma_ops. These people need per-device dma_ops and we can do stack
> per-device dma_ops?

Anybody who does stack ops in your scheme would need to hook into new
device creation and an own per device saving pointer. Also there
are livetime issues when to wrap.

It's certainly possible, but likely complicated

-Andi


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

On Fri, 16 May 2008 07:24:33 +0200
Andi Kleen wrote:

> FUJITA Tomonori wrote:
> > On Thu, 15 May 2008 12:48:04 +0200
> > Andi Kleen wrote:
> >
> >>> I thought that KVM people want to do it per device (in the first
> >>> case). So with my patchse, they can replace the dma_ops pointer in
> >>> dev_archdata with what they want.
> >> But where would they save the original pointer?
> >
> > Yeah, we need an extra mechanism for that but it's same for the
> > system-wide dma_ops pointer (i.e. without my patches), isn't it?
> >
> > I'm still not sure how this patchset make it impossible to have stack
> > dma_ops. These people need per-device dma_ops and we can do stack
> > per-device dma_ops?
>
> Anybody who does stack ops in your scheme would need to hook into new
> device creation and an own per device saving pointer. Also there
> are livetime issues when to wrap.

But is that what those people want, setting up dma_ops per device?

I think that creating a hook is not difficult and we could put a
mechnism to save a pointer in asm-x86/{dma-mapping.h, device.h}.


> It's certainly possible, but likely complicated

Hmm, let's see what those people think about on this. I'll repost a
patchset for -mm with CC'ing those people.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/