qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices
Date: Wed, 25 Aug 2010 11:49:19 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6

On 08/25/2010 10:17 AM, Isaku Yamahata wrote:
On Wed, Aug 25, 2010 at 07:55:27AM -0500, Anthony Liguori wrote:
Maybe we can merge the patches.
As for your patch, I have some comment.
- bus itself may want its own handler. At lease pci bus needs it.
    And propagating reset signal to children is up to the bus controller.

I disagree.  Reset should be equivalent to power off + init and it's not
something that can be selectively propagated.

There are different types of bus level resets and it may make sense to
model that in the PCI layer but the qdev reset is a power cycle
semantically.

I think using a walker pattern is a stronger design than having each
reset function do it's own transversal because the later has the
potential to introduce bugs.
Warm reset is different from cold reset, so reset isn't equivalent to
a power cycle.

But qdev reset is not warm reset. It's cold reset. IOW, it's called when the device is first powered up.

  Typically registers which report errors must retain the
contents across warm reset, but doesn't across a power cycle.
I can see the reset call back is called when both power on and warm reset,
but I don't see why qdev_reset() is a power cycle semantically.

Although your current patch might work for me at the moment,
the claim that qdev_reset() == a power cycle worries me.

How about adding a argument to distinguish reset type?
Something like QEMU_RESET_COLD, QEMU_RESET_WARM.

Before approaching this, I think we ought to better understand exactly what type of reset semantics we would need to support in the future.

I think that starts by understanding exactly what's guaranteed and understanding what the use cases are for it.

Regards,

Anthony Liguori



reply via email to

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