qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 00/38] Delay destruction of memory regions to


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v2 00/38] Delay destruction of memory regions to instance_finalize
Date: Tue, 17 Sep 2013 19:29:28 +0300

On Tue, Sep 17, 2013 at 06:13:51PM +0200, Paolo Bonzini wrote:
> Il 17/09/2013 17:59, Michael S. Tsirkin ha scritto:
> > Yes but just not freeing it is unlikely to be enough.
> > We need to make sure data structures are consistent.
> > So this really needs to be done carefully, device by device.
> 
> Of course.  I checked SCSI already and it's sane.
> 
> >>>> - del_vm_change_state_handler
> >>
> >> Same here: user can stop/cont between exit and finalize, for example
> >> because the I/O failed.
> > 
> > Device that is not guest visible is very unlikely to
> > care about whether guest is running.
> 
> Most devices do not care at all whether the guest is running. :)  If
> they do, they usually just use vm_clock.
> 
> But retrying failed I/O uses qemu_add_vm_change_set_handler, and that
> has to be done even after the device is not guest visible anymore.
> 
> BTW, qemu_del_nic is another one that I forgot to mention.  You could
> have MMIO that triggers a transmit while the device is going down, for
> example.
> 
> Paolo

Wait a second.  This API simply does not make sense.
If region is not visible it's MMIO really mustn't trigger,
exit or no exit.  Disabling region and still getting op callbacks
afterwards is not what any caller of this API expects.

I'm not sure what to do about the bounce buffer thing
but it needs to be fixed some other way without
breaking API.

-- 
MST



reply via email to

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