[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.4 1/2] core: reset handler for bus-less de

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH for-2.4 1/2] core: reset handler for bus-less devices
Date: Mon, 13 Jul 2015 16:56:33 +0100

On 13 July 2015 at 16:38, Cornelia Huck <address@hidden> wrote:
> So why does a pure Device have a reset callback then that is not called
> by default?

This is (as I understand it) basically historical legacy from
qdev. The qdev model puts every device on a bus of some kind,
and then says that it's the bus that has responsibility for
resetting the devices on it. We've now generalised that to
allowing devices that don't really sit on buses, but because
we still have a lot of code in the system that assumes the
reset-is-by-the-bus model (and for cases like PCI depends on
that ordering) we can't shift to "just reset every Device object
in the system". So the current setup is that every Device needs
to either (a) live on a bus that handles reset for it or
(b) arrange to call reset itself or (c) require the code which
creates it to arrange for reset to be called (which is what CPU
objects do, for instance -- the board code has to register a
reset handler which calls cpu_reset()).

> Really, I think we're moving in circles here. First, the device should
> not live on the sysbus as it does not fit the perceived sysbus
> semantics. As there is no natural bus for it to live on, it becomes a
> pure device. Which is not reset, because somehow a generic callback is
> not called generically.

I agree it's confusing, but I think adding a generic call to reset
at this point in the release cycle is really dangerous. For
better or worse, a lot of devices in the system expect to be
reset in the way they are currently. There's definitely
scope for improving/fixing the current code, but I think it's
more upheaval than we can do for this release.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]