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

[Wei Xu <wexu2@cisco.com>]

Isaku and Anthony:

This is excellent discussion! Thanks for forwarding.

Wei Xu

wexu2@cisco.com


On 8/26/10 8:52 PM, "Isaku Yamahata" <yamahata@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.
>>> 
>>>    
>>