[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87pmu8cn2d.fsf@mpe.ellerman.id.au>
Date: Fri, 20 Aug 2021 22:34:02 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Daniel Axtens <dja@...ens.net>,
Xianting Tian <xianting.tian@...ux.alibaba.com>,
gregkh@...uxfoundation.org, jirislaby@...nel.org, amit@...nel.org,
arnd@...db.de, osandov@...com
Cc: Xianting Tian <xianting.tian@...ux.alibaba.com>,
shile.zhang@...ux.alibaba.com, linuxppc-dev@...ts.ozlabs.org,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars()
Daniel Axtens <dja@...ens.net> writes:
> Xianting Tian <xianting.tian@...ux.alibaba.com> writes:
>
>> As well known, hvc backend driver(eg, virtio-console) can register its
>> operations to hvc framework. The operations can contain put_chars(),
>> get_chars() and so on.
>>
>> Some hvc backend may do dma in its operations. eg, put_chars() of
>> virtio-console. But in the code of hvc framework, it may pass DMA
>> incapable memory to put_chars() under a specific configuration, which
>> is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
>
> We could also run into issues on powerpc where Andrew is working on
> adding vmap-stack but the opal hvc driver assumes that it is passed a
> buffer which is not in vmalloc space but in the linear mapping.
The right fix for that is our code that calls opal has to be careful
that it's not passing vmalloc addresses.
We have many cases where we pass stack variables to opal, they'll all
have to be fixed to pass the underlying phyiscal/linear map address. The
opal hvc code will just be one more case of that.
cheers
Powered by blists - more mailing lists