On 08/31/2010 08:46 AM, Avi Kivity wrote:
On 08/31/2010 04:34 PM, Anthony Liguori wrote:
On 08/31/2010 08:29 AM, Avi Kivity wrote:
Note, for most devices there's no difference. x86 has INIT and
RESET, with the keyboard controller RESET signal sometimes wired to
INIT, and RAM doesn't have RESET. Otherwise most devices don't see
a difference.
Yes, that's why I'm wondering if we can just get away with using a
simple reset() callback and for the handful of devices that don't do
a full reset, they can just move the state unaffected by warm reset
to ->init().
This seems reasonable.
But I'm still not sure whether the reset signal can be deliver based on
a pre-order transversal or whether a custom transversal was required
that each bus participates in.
For cold reset, I'd rather approach it as a device destroy + create.
This means that given a DeviceState, we need to collect enough
information to recreate the device. I'm not 100% sure we have that
today but if we solve that problem, it means we can migrate the
device tree during migration which is a feature I'd really like to see.
Why do we need a cold reset at all? it doesn't map to anything.
That's why I'm suggesting a second-class approach to implementing it if
someone really wants it.
Regards,
Anthony Liguori
