On 09/17/2013 06:01 PM, Paolo Bonzini wrote:
Il 17/09/2013 08:44, Wenchao Xia ha scritto:
Just one question: where is the caller of .instance_finalize(), did
I missed that patch?
It's called by qom/object.c.
Paolo
I see, thanks for tipping.
Il 18/09/2013 07:48, Michael S. Tsirkin ha scritto:
So I think the fix is actually obeying ordering rules,
that is know that write is in progress
and flush on read.
I think this can be modeled as a generic, synchronous
(*busmaster_cancel)(PCIDevice*) callback, that is called after bus
master
On Wed, Sep 18, 2013 at 09:40:19AM +0200, Paolo Bonzini wrote:
Il 18/09/2013 07:48, Michael S. Tsirkin ha scritto:
So I think the fix is actually obeying ordering rules,
that is know that write is in progress
and flush on read.
I think this can be modeled as a generic, synchronous
Il 18/09/2013 10:41, Michael S. Tsirkin ha scritto:
On Wed, Sep 18, 2013 at 09:40:19AM +0200, Paolo Bonzini wrote:
Il 18/09/2013 07:48, Michael S. Tsirkin ha scritto:
So I think the fix is actually obeying ordering rules,
that is know that write is in progress
and flush on read.
I think
On 18 September 2013 20:26, Paolo Bonzini pbonz...@redhat.com wrote:
But does guest code actually care? In many cases, I suspect that
sticking a smp_rmb() in the read side of unlocked register accesses,
and a smp_wmb() in the write side, will do just fine. And add a
compatibility property to
Il 18/09/2013 13:56, Peter Maydell ha scritto:
But does guest code actually care? In many cases, I suspect that
sticking a smp_rmb() in the read side of unlocked register accesses,
and a smp_wmb() in the write side, will do just fine. And add a
compatibility property to place a device
On 18 September 2013 22:11, Paolo Bonzini pbonz...@redhat.com wrote:
Il 18/09/2013 13:56, Peter Maydell ha scritto:
But does guest code actually care? In many cases, I suspect that
sticking a smp_rmb() in the read side of unlocked register accesses,
and a smp_wmb() in the write side, will
Il 18/09/2013 15:19, Peter Maydell ha scritto:
There's nothing magic, really. Both PV and real devices have been doing
it forever by placing some registers in RAM instead of MMIO, and
communicating synchronization points via interrupts and doorbell registers.
Sure, but that's a hardware
δΊ 2013/9/3 20:32, Paolo Bonzini ει:
QOM splits the destruction of a device in two phases:
- unrealize, also known as exit from qdev times, should isolate
the device from the guest. After unrealize returns, the guest
should not be able to issue new requests.
- instance_finalize will
On Tue, Sep 03, 2013 at 02:32:51PM +0200, Paolo Bonzini wrote:
QOM splits the destruction of a device in two phases:
- unrealize, also known as exit from qdev times, should isolate
the device from the guest. After unrealize returns, the guest
should not be able to issue new requests.
Il 17/09/2013 08:44, Wenchao Xia ha scritto:
Just one question: where is the caller of .instance_finalize(), did
I missed that patch?
It's called by qom/object.c.
Paolo
On Tue, Sep 03, 2013 at 02:32:51PM +0200, Paolo Bonzini wrote:
QOM splits the destruction of a device in two phases:
- unrealize, also known as exit from qdev times, should isolate
the device from the guest. After unrealize returns, the guest
should not be able to issue new requests.
Il 17/09/2013 14:47, Michael S. Tsirkin ha scritto:
Ergo, to make sure a referenced MR does not get
destroyed, we must make sure only finalize
calls memory_region_destroy.
So I think this patchset should do exactly that,
not try to move out more stuff to finalize.
Yes, this is the part of
On Tue, Sep 17, 2013 at 04:41:45PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 14:47, Michael S. Tsirkin ha scritto:
Ergo, to make sure a referenced MR does not get
destroyed, we must make sure only finalize
calls memory_region_destroy.
So I think this patchset should do exactly that,
Il 17/09/2013 16:45, Michael S. Tsirkin ha scritto:
On Tue, Sep 17, 2013 at 04:41:45PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 14:47, Michael S. Tsirkin ha scritto:
Ergo, to make sure a referenced MR does not get
destroyed, we must make sure only finalize
calls memory_region_destroy.
So I
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.
-
On Tue, Sep 17, 2013 at 05:41:52PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 16:45, Michael S. Tsirkin ha scritto:
On Tue, Sep 17, 2013 at 04:41:45PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 14:47, Michael S. Tsirkin ha scritto:
Ergo, to make sure a referenced MR does not get
destroyed,
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
On Tue, Sep 17, 2013 at 06:58:37PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 18:29, Michael S. Tsirkin ha scritto:
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.
Wait a second.
Il 17/09/2013 18:29, Michael S. Tsirkin ha scritto:
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.
Wait a second. This API simply does not make sense.
If region is not visible it's
On Tue, Sep 17, 2013 at 07:16:15PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 19:07, Michael S. Tsirkin ha scritto:
After memory_region_del_subregion returns,
it's a promise that there will not be accesses
to the region.
It's racy anyway. You can have memory_region_del_subregion happen
Il 17/09/2013 19:07, Michael S. Tsirkin ha scritto:
After memory_region_del_subregion returns,
it's a promise that there will not be accesses
to the region.
It's racy anyway. You can have memory_region_del_subregion happen one
clock cycle after the other (physical) CPU has done checked that
Il 17/09/2013 19:26, Michael S. Tsirkin ha scritto:
On Tue, Sep 17, 2013 at 07:16:15PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 19:07, Michael S. Tsirkin ha scritto:
After memory_region_del_subregion returns,
it's a promise that there will not be accesses
to the region.
It's racy anyway.
On Tue, Sep 17, 2013 at 09:07:05PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 19:26, Michael S. Tsirkin ha scritto:
On Tue, Sep 17, 2013 at 07:16:15PM +0200, Paolo Bonzini wrote:
Il 17/09/2013 19:07, Michael S. Tsirkin ha scritto:
After memory_region_del_subregion returns,
it's a promise
Il 17/09/2013 21:51, Michael S. Tsirkin ha scritto:
A much more interesting case is e.g. disabling memory.
E.g.
config write (disable memory)
read (flush out outstanding writes)
write - must now have no effect
This works already. memory_region_del_subregion is synchronous, and
will remain
On Wed, Sep 18, 2013 at 12:02:51AM +0200, Paolo Bonzini wrote:
Il 17/09/2013 21:51, Michael S. Tsirkin ha scritto:
A much more interesting case is e.g. disabling memory.
E.g.
config write (disable memory)
read (flush out outstanding writes)
write - must now have no effect
This
Il 03/09/2013 14:32, Paolo Bonzini ha scritto:
QOM splits the destruction of a device in two phases:
- unrealize, also known as exit from qdev times, should isolate
the device from the guest. After unrealize returns, the guest
should not be able to issue new requests.
-
QOM splits the destruction of a device in two phases:
- unrealize, also known as exit from qdev times, should isolate
the device from the guest. After unrealize returns, the guest
should not be able to issue new requests.
- instance_finalize will reclaim the memory. This is only called
28 matches
Mail list logo
