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

[Isaku Yamahata]

On Wed, Aug 25, 2010 at 11:49:19AM -0500, Anthony Liguori wrote:
> 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.

No. It's not true.
Surely qemu_system_reset() is called on qemu startup from main().
But it is also called from main_loop() as warm reset.
qemu_system_reset_request() is called when warm reset is requested.
That is, qemu_system_reset() doesn't distinguish warm reset from
cold reset. Thus qdev_reset() doesn't.


>>   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.

Fair enough. How about the followings?
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()

        
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.

-- 
yamahata