This patchset converts the ps2 keyboard and mouse devices to 3-phase
reset. The rationale here is that it would be nice to get rid of the
device_class_set_parent_reset() function, which is used by
legacy-reset subclasses which want to chain to their parent's reset
function. There aren't very many of these devices in total, and if we
convert them all to 3-phase reset they can use the 3-phase-reset
equivalent (resettable_class_set_parent_phases()).  Eventually this
will then let us simplify the transitional code for handling old-style
device reset.

This is one of a number of patchsets to do this that I'm planning to
write and send out over the next few weeks. It's all 8.0 material.

thanks
-- PMM

Peter Maydell (2):
  hw/input/ps2: Convert TYPE_PS2_DEVICE to 3-phase reset
  hw/input/ps2.c: Convert TYPE_PS2_{KBD,MOUSE}_DEVICE to 3-phase reset

 include/hw/input/ps2.h |  2 +-
 hw/input/ps2.c         | 45 +++++++++++++++++++++++++++++-------------
 2 files changed, 32 insertions(+), 15 deletions(-)

-- 
2.25.1

On Wed, 9 Nov 2022 at 17:00, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> This patchset converts the ps2 keyboard and mouse devices to 3-phase
> reset. The rationale here is that it would be nice to get rid of the
> device_class_set_parent_reset() function, which is used by
> legacy-reset subclasses which want to chain to their parent's reset
> function. There aren't very many of these devices in total, and if we
> convert them all to 3-phase reset they can use the 3-phase-reset
> equivalent (resettable_class_set_parent_phases()).  Eventually this
> will then let us simplify the transitional code for handling old-style
> device reset.


I plan to pick these up and send them in a pullreq together
with various other reset-related patches of mine, unless
you'd prefer them to go in some other way.

thanks
-- PMM

On 09/11/2022 17:00, Peter Maydell wrote:

> This patchset converts the ps2 keyboard and mouse devices to 3-phase
> reset. The rationale here is that it would be nice to get rid of the
> device_class_set_parent_reset() function, which is used by
> legacy-reset subclasses which want to chain to their parent's reset
> function. There aren't very many of these devices in total, and if we
> convert them all to 3-phase reset they can use the 3-phase-reset
> equivalent (resettable_class_set_parent_phases()).  Eventually this
> will then let us simplify the transitional code for handling old-style
> device reset.
> 
> This is one of a number of patchsets to do this that I'm planning to
> write and send out over the next few weeks. It's all 8.0 material.
> 
> thanks
> -- PMM
> 
> Peter Maydell (2):
>    hw/input/ps2: Convert TYPE_PS2_DEVICE to 3-phase reset
>    hw/input/ps2.c: Convert TYPE_PS2_{KBD,MOUSE}_DEVICE to 3-phase reset
> 
>   include/hw/input/ps2.h |  2 +-
>   hw/input/ps2.c         | 45 +++++++++++++++++++++++++++++-------------
>   2 files changed, 32 insertions(+), 15 deletions(-)

I haven't used the new ResettableClass myself previously, however it seems to match 
the excellent documentation at https://qemu.readthedocs.io/en/latest/devel/reset.html 
so feel free to add my Acked-by tag.

One part that did stand out to me in the docs is the part that reads "For now 
migration of a device or bus in reset is not supported. Care must be taken not to 
delay resettable_release_reset() after its resettable_assert_reset() counterpart". Is 
this still a valid concern and something we need to think about? I'm thinking about 
if a guest triggers a SCSI bus or PCI bus reset for example.


ATB,

Mark.

On Thu, 10 Nov 2022 at 10:36, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> I haven't used the new ResettableClass myself previously, however it seems to match
> the excellent documentation at https://qemu.readthedocs.io/en/latest/devel/reset.html
> so feel free to add my Acked-by tag.
>
> One part that did stand out to me in the docs is the part that reads "For now
> migration of a device or bus in reset is not supported. Care must be taken not to
> delay resettable_release_reset() after its resettable_assert_reset() counterpart". Is
> this still a valid concern and something we need to think about? I'm thinking about
> if a guest triggers a SCSI bus or PCI bus reset for example.

That only matters if there's a way for the guest to hold the device
in reset, as opposed to resetting it as a point event. This is
theoretically possible to do with the new API, and was simply
impossible with the old API because with the old one reset was
always a one-shot point event.

thanks
-- PMM

On 10/11/2022 11:22, Peter Maydell wrote:

> On Thu, 10 Nov 2022 at 10:36, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> I haven't used the new ResettableClass myself previously, however it seems to match
>> the excellent documentation at https://qemu.readthedocs.io/en/latest/devel/reset.html
>> so feel free to add my Acked-by tag.
>>
>> One part that did stand out to me in the docs is the part that reads "For now
>> migration of a device or bus in reset is not supported. Care must be taken not to
>> delay resettable_release_reset() after its resettable_assert_reset() counterpart". Is
>> this still a valid concern and something we need to think about? I'm thinking about
>> if a guest triggers a SCSI bus or PCI bus reset for example.
> 
> That only matters if there's a way for the guest to hold the device
> in reset, as opposed to resetting it as a point event. This is
> theoretically possible to do with the new API, and was simply
> impossible with the old API because with the old one reset was
> always a one-shot point event.

I see, thanks. And the documentation confirms that resettable_reset() is an assert 
immediately followed by a release so that shouldn't be an issue for 
device_cold_reset() and bus_cold_reset() calling the new Resettable inteface.


ATB,

Mark.