Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices

[Anthony Liguori <aliguori@us.ibm.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 10 January 2013 12:12, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 10/01/2013 12:59, Peter Maydell ha scritto:
>>>>>>> >>> > It's possible.  I'll move the SCSI bus away from qdev reset.
>>>>>>> >>> > Anthony/Michael, can you help doing the same with PCIDevice?  And
>>>>>>> >>> > perhaps Peter and Andreas with sysbus?
>>>>> >> What does it even mean to reset a sysbus? Do we do it anywhere?
>>>>> >> (it looks like vl.c does, just as a shortcut so memory mapped devices
>>>>> >> get their reset hooks called?)
>>> So how should it work instead? I kind of feel like all qdev devices should
>>> get their reset hook called on machine reset, regardless of bus [since it's
>>> modelling power cycling the whole system], but would that break
>>> something?
>>
>> It's just an implementation detail.  Right now we have a common
>> callback.  The idea is to give each bus its own callback.  In the case
>> of sysbus it would just call a method; for PCI it would reset some
>> configuration and then call a method; for SCSI there is no need to call
>> a method at all; and so on.
>
> But machine reset shouldn't call bus specific PCI or SCSI reset
> methods -- we've just effectively yanked the power to the VM
> so everything should just reset as if it was freshly constructed.
>
> A bus-specific reset method would be for buses where the bus
> itself has some sort of guest-triggerable reset (by prodding the
> chipset, for instance).

The challenge is how we go from what we have to what we want.

Right now we have DeviceState::reset.  This is used both as a soft and
hard reset.

What I would propose is that we:

  s/DeviceState::reset/DeviceState::hard_reset/g

Then introduce PCIDevice::soft_reset.  We can convert the PCI layer to
call soft_reset() instead of hard_reset.

Over time, it would be great if we could find a way to implement
hard_reset in terms of device destruction/recreation but we're not there
yet.

I think the reset/hard_reset rename can be done via sed mostly.

Would this solve the bug that you're trying to fix Michael/Paolo?

Regards,

Anthony Liguori


>> In addition, navigating the qdev tree should be explicit in the methods.
>>  It will not happen anymore via the "magic" qdev_reset_all.
>
> *Something* has to say "call reset for every qdev object in the
> system", surely?
>
> -- PMM