qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 00/15] qdev: make reset semantics more clear and consistent, reset qbuses under virtio devices
Date: Thu, 10 Jan 2013 12:31:24 +0000

On 10 January 2013 12:12, Paolo Bonzini <address@hidden> 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).

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]