Hi Eric,
On Wed, Feb 14, 2018 at 11:11 AM, Auger Eric <eric.au...@redhat.com> wrote:
> On 14/02/18 10:43, Geert Uytterhoeven wrote:
>> On Wed, Feb 14, 2018 at 10:09 AM, Auger Eric <eric.au...@redhat.com> wrote:
>>> On 13/02/18 17:36, Geert Uytterhoeven wrote:
>>>> Vfio-platform requires reset support, provided either by ACPI, or, on DT
>>>> platforms, by a device-specific reset driver matching against the
>>>> device's compatible value.
>>>>
>>>> On many SoCs, devices are connected to an SoC-internal reset controller,
>>>> and can be reset in a generic way. Hence add support to reset such
>>>> devices using the reset controller subsystem, provided the reset
>>>> hierarchy is described correctly in DT using the "resets" property.
>>>
>>> I first acknowledge I am not familiar with what those reset controllers
>>> do in practice. My fear is that we may rely on generic SW pieces that
>>> may not be adapted to passthrough constraints. We must guarantee that
>>> any DMA access attempted by the devices are stopped and any interrupts
>>> gets stopped. Can we guarantee that the reset controller always induce
>>> that? Otherwise we may leave the door opened to badly reset assigned
>>> devices.
>>
>> An on-SoC reset controller is basically a block controlling signals to the
>> reset inputs of the individual on-SoC devices.
>> On Renesas ARM SoCs, this allows to do a full reset of the attached device.
>>
>> Of course the exact semantics depend on the actual SoC.
> that's the issue actually.
>> If e.g. DMA and interrupts are not stopped for a specific device on a
>> specific SoC, it still needs a device-specific reset driver, matching against
>> the appropriate compatible value, cfr. the quoted paragraph below.
> yes but by default we still accept the reset controller solution.
>>
>> You could add a whitelist for of_machine_is_compatible() or
>> of_device_is_compatible(), but that will grow large fast.
> Could be the kind of solution needed. At the moment the list of assigned
> platform devices is pretty reduced.
>
> Couldn't we imagine additional dt properties to emphasize the fact a
> platform device is passthrough friendly in terms of reset, either
> through a reset controller or exposing a single reg that need to be
> reset for full reset to be achieved, in accordance with assignment
> constraints. That way, the driver writer would somehow certify the
> device is eligible for passthrough. One of the issue today is that the
> vfio platform reset driver is not maintained by the native driver
> maintainer.
I'm not so fond of adding more DT properties for this. They can be abused
as well.
In general, if there's a "resets" DT property, it means the device can be
reset through the pointed-by reset controller. So that's the common case,
which I'd like to optimize/simplify for.
If more is needed, a separate (device-specific) vfio_reset handler needs
to be written, by the people that know the hardware.
> I think if people want to do platform passthrough, they need to devise
> their HW IPs so that this reset modality is simplified by exposing this
> kind of single reg and then dt description may expose this. Also if
> possible, the dt node must be as simple/generic as possible to avoid
> writing a huge dt node creation function on QEMU side and avoid
> dependencies on other nodes.
Yes. It all depends on sane hardware ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
