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: Michael S. Tsirkin
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 17:01:18 +0200

On Thu, Jan 10, 2013 at 08:14:43AM -0600, Anthony Liguori wrote:
> Peter Maydell <address@hidden> writes:
> 
> > 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).
> 
> 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

I don't think we need a rename to fix a specific bug.
The bugs Paolo found can be fixed in virtio and virtio-scsi.

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