qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Isaku Yamahata <yamahata@valinux.co.jp>
Cc: qemu-devel@nongnu.org,
	Alex Williamson <alex.williamson@redhat.com>,
	glommer@redhat.com, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] qdev: Reset hotplugged devices
Date: Thu, 26 Aug 2010 08:04:44 -0500	[thread overview]
Message-ID: <4C76666C.7020106@codemonkey.ws> (raw)
In-Reply-To: <20100826083821.GC16489@valinux.co.jp>

On 08/26/2010 03:38 AM, Isaku Yamahata wrote:
>
> 	QEMU_RESET_COLD
>    

BTW, just from a implementation perspective, I'd rather have multiple 
reset callbacks in qdev instead of having a single callback with a type 
flag.  A type flag implies that every callback has to handle all cases 
whereas with separate callbacks, if a device doesn't implement 
warm_reset we can easily default it to reset (which is a cold reset).

Regards,

Anthony Liguori

> 	Guarantee:
> 	The internal status must be same to qdev_init() + qdev_reset()
>
> 	
> warm reset
> 	system reset without cycling the supplied power.
> 	Use case:
> 	In qemu, system_reset() in main_loop(). There are many places
> 	which calls qemu_system_reset_request().
> 	Some state are retained across warm reset. Like PCIe AER, error
> 	reporting registers need to keep its contents across warm reset
> 	as OS would examine them and report it when hardware errors caused
> 	warm reset.
> 	QEMU_RESET_WARM
> 	
>
> bus reset
> 	Reset bus and devices on the bus.
> 	Bus reset is usually triggered when cold reset, warm reset and
> 	commanding the bus controller to reset the child bus.
> 	When bus reset is triggered as command to bus controller,
> 	the effect is usually same to warm reset on devices on the bus.
>
> 	Typically on parallel bus, bus reset is started by asserting
> 	a designated signal.
> 	Example: PCI RST#, ATA RESET-, SCSI RST
> 	
> 	Use case:
> 	bus reset as result of programming bus controller.
> 	Qemu is currently missing it which I'd like to fill for pci bus.
> 	ATA and SCSI could benefit from this.
> 	QEMU_RESET_WARM with bus.
> 	Guarantee:
> 	device state under the bus is same as warm reset.
>
>
> device/function reset:
> 	Reset triggered by sending reset command to a device.
> 	This is bus/device specific.
> 	There might be many reset commands whose effects are different.
> 	Example: PCI FLR, ATA DEVICE RESET command,
>                   scsi bus device reset message.
>
> 	This reset is bus specific, so it wouldn't be suitable for qdev
> 	frame work and could be handled by each bus level.
>
> 	
> hot reset:
> 	I just put it here for completeness because pcie defines hot reset.
> 	A reset propagated in-band across a Link using a Physical Layer
> 	mechanism.
> 	Qemu doesn't emulate physical layer, so we don't care it.
> 	From software point of view, hot reset has same effect to warm reset.
>
>    

  parent reply	other threads:[~2010-08-26 13:04 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-03 16:19 [Qemu-devel] [PATCH] qdev: Reset hotplugged devices Alex Williamson
2010-08-03 17:41 ` [Qemu-devel] " Glauber Costa
2010-08-20  9:00 ` [Qemu-devel] " Markus Armbruster
2010-08-20 12:41   ` Alex Williamson
2010-08-20 15:47     ` Markus Armbruster
2010-08-20 15:56       ` Anthony Liguori
2010-08-20 16:14         ` Markus Armbruster
2010-08-20 18:12           ` Anthony Liguori
2010-08-20 22:05             ` Alex Williamson
2010-08-21 10:07             ` Markus Armbruster
2010-08-21 15:19               ` Anthony Liguori
2010-08-23 11:25             ` [Qemu-devel] " Paolo Bonzini
2010-08-23 13:27               ` Anthony Liguori
2010-08-25  3:07         ` [Qemu-devel] " Isaku Yamahata
2010-08-25 12:55           ` Anthony Liguori
2010-08-25 15:17             ` Isaku Yamahata
2010-08-25 16:49               ` Anthony Liguori
2010-08-26  8:38                 ` Isaku Yamahata
2010-08-26 13:02                   ` Anthony Liguori
2010-08-27  3:52                     ` Isaku Yamahata
2010-08-27 17:43                       ` Wei Xu
2010-08-27  7:28                     ` Isaku Yamahata
2010-08-26 13:04                   ` Anthony Liguori [this message]
2010-08-26 13:15             ` Avi Kivity
2010-08-26 13:25               ` Anthony Liguori
2010-08-26 14:29                 ` Avi Kivity
2010-08-26 17:39                   ` Blue Swirl
2010-08-23 12:00   ` Avi Kivity
2010-08-23 12:21     ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C76666C.7020106@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=glommer@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yamahata@valinux.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).