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 07:55:27 -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/24/2010 10:07 PM, Isaku Yamahata wrote:
On Fri, Aug 20, 2010 at 10:56:57AM -0500, Anthony Liguori wrote:
The real problem is how we do reset.  We shouldn't register a reset
handler for every qdev device but rather register a single reset handler
that walks the device tree and calls reset on every reachable device.

Then we can always call reset in init() and there's no need to have a
dev->hotplugged check.  The qdev device tree reset handler should not be
registered until *after* we call qemu_system_reset() after creating the
device model which will ensure that we don't do a double reset.
I don't see why you re-invent the patch.
Please see the patches I sent out on August 5.
http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00377.html
http://lists.nongnu.org/archive/html/qemu-devel/2010-08/msg00383.html

I honestly didn't connect the two but it's now obvious to me that they overlap significantly.

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.

Regards,

Anthony Liguori

- child devices should be reset before parent.
   This doesn't matter much though.





reply via email to

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