Isaku and Anthony: This is excellent discussion! Thanks for forwarding.
Wei Xu we...@cisco.com On 8/26/10 8:52 PM, "Isaku Yamahata" <yamah...@valinux.co.jp> wrote: > I added CC for those who might be interested in this discussion. > > On Thu, Aug 26, 2010 at 08:02:38AM -0500, Anthony Liguori wrote: >> On 08/26/2010 03:38 AM, Isaku Yamahata wrote: >>> >>>> I think that starts by understanding exactly what's guaranteed and >>>> understanding what the use cases are for it. >>>> >>> Fair enough. How about the followings? >>> >> >> Thanks for enumerating. >> >>> This is just a starting point. I borrowed terminology pci/pcie spec. >>> >>> >>> reset >>> Bring the state of hardware state to consistent state. >>> (some state might be left unknown.) >>> >>> >>> system reset >>> a hardware mechanism for setting or returning all hardware states >>> to the initial conditions. >>> Use case: >>> In qemu, system_system_reset(). >>> >>> >>> cold reset(power on reset) >>> system reset following the application of power. >>> Use case: >>> In qemu, system_reset() in main(). >>> We might want to use this as a power cycle. >>> When a device is hot plugged, the device should be cold reset too. >>> This is your motivation. >>> QEMU_RESET_COLD >>> Guarantee: >>> The internal status must be same to qdev_init() + qdev_reset() >>> >> >> This is what we do today in QEMU and from a functional perspective it >> covers the type of function we need today. >> >>> >>> 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 >>> >> >> With AER, I can't imagine that this matters that much unless we're doing >> PCI passthrough, right? > > Even without PCI passthrough, AER errors can be injected into emulated > pci/pcie > devices in a virtual pcie bus hierarchy from qemu command line. > This is useful to test guest OS AER handler. > > >> So maybe the way we should frame this discussion is, what's the type of >> reset semantics that we need to support for PCI passthrough? The next >> question after that is how do we achieve the different types of reset >> for passthrough devices? > > What I want is hot reset in pcie terminology on a virtual bus as > PCI_BRIDGE_CTL_BUS_RESET emulation and propagated reset on devices/child > buses which might be a directly assigned. > In direct assigned device case, device-assignment code would be notified the > reset. > > As hot reset has same effect to warm reset in functionality sense > (the difference is the way to signal it in physical/signal layer which > qemu doesn't care), > I'd like to implement pci bus reset as triggering warm reset on a > (virtual) bus by utilizing qdev frame work. > This would be applicable to ata, scsi, I suppose. > > > It's another story how to virtualize hot reset on a given directly assigned > pci function or a pcie bus hierarchy. For example, as PCI device assignment > is done per function basis, co-existing functions in the same card shouldn't > be reset. > Another example is, virtual pci bus hierarchy might be reset, but it would > be difficult problem how to map the virtual bus topology to host bus topology. > > thanks, > >> BTW, if you could transfer some of this discussion to a wiki page on >> qemu.org, I think that would be extremely valuable. >> >> Regards, >> >> Anthony Liguori >> >>> 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. >>> >>> >>