On Mon, Dec 21, 2020 at 08:16:00PM +0100, Paolo Bonzini wrote:
> On 21/12/20 19:54, Eduardo Habkost wrote:
> > On Sun, Dec 20, 2020 at 10:25:25AM +0100, Paolo Bonzini wrote:
> > > On 18/12/20 23:32, Eduardo Habkost wrote:
> > > > Who owns the FlatView reference, exactly?
> > >
> > > The AddressSpa
On 21/12/20 19:54, Eduardo Habkost wrote:
On Sun, Dec 20, 2020 at 10:25:25AM +0100, Paolo Bonzini wrote:
On 18/12/20 23:32, Eduardo Habkost wrote:
Who owns the FlatView reference, exactly?
The AddressSpace. The device creates the AddressSpace, which holds a
reference to the MemoryRegion thro
On Sun, Dec 20, 2020 at 10:25:25AM +0100, Paolo Bonzini wrote:
> On 18/12/20 23:32, Eduardo Habkost wrote:
> > Who owns the FlatView reference, exactly?
>
> The AddressSpace. The device creates the AddressSpace, which holds a
> reference to the MemoryRegion through FlatView and AddressSpaceDispat
On 18/12/20 23:32, Eduardo Habkost wrote:
Who owns the FlatView reference, exactly?
The AddressSpace. The device creates the AddressSpace, which holds a
reference to the MemoryRegion through FlatView and AddressSpaceDispatch,
which holds a reference to the device.
By destroying the address
On Fri, Dec 18, 2020 at 07:49:24AM +, Mark Cave-Ayland wrote:
> On 10/11/2020 11:40, Paolo Bonzini wrote:
>
> > On 10/11/20 12:14, Mark Cave-Ayland wrote:
> > > There are 2 possible solutions here: 1) ensure QOM objects that add
> > > address spaces during instance init have a corresponding in
On 10/11/2020 11:40, Paolo Bonzini wrote:
On 10/11/20 12:14, Mark Cave-Ayland wrote:
There are 2 possible solutions here: 1) ensure QOM objects that add address spaces
during instance init have a corresponding instance finalize function to remove them
or 2) move the creation of address spaces
On Tue, Nov 10, 2020 at 12:46:48PM -0500, Eduardo Habkost wrote:
> On Tue, Nov 10, 2020 at 04:08:16PM +0100, Paolo Bonzini wrote:
> > On 10/11/20 16:03, Eduardo Habkost wrote:
> > > > Does anyone have any arguments for which solution is preferred?
> > > I'd say (2) is preferred, as we don't expect
On Tue, Nov 10, 2020 at 04:08:16PM +0100, Paolo Bonzini wrote:
> On 10/11/20 16:03, Eduardo Habkost wrote:
> > > Does anyone have any arguments for which solution is preferred?
> > I'd say (2) is preferred, as we don't expect object_new(T) to
> > have any side effects outside the object instance st
On 10/11/20 16:03, Eduardo Habkost wrote:
Does anyone have any arguments for which solution is preferred?
I'd say (2) is preferred, as we don't expect object_new(T) to
have any side effects outside the object instance state.
Since there are no listeners, the side effects of address_space_init(
CCing Paolo, the Memory API maintainer.
On Tue, Nov 10, 2020 at 11:14:39AM +, Mark Cave-Ayland wrote:
> Hi all,
>
> This email follows on from my investigation of intermittent Travis-CI
> failures in make check's device-introspect test when trying to add the patch
> at https://lists.gnu.org/a
On 10/11/20 12:14, Mark Cave-Ayland wrote:
There are 2 possible solutions here: 1) ensure QOM objects that add
address spaces during instance init have a corresponding instance
finalize function to remove them or 2) move the creation of address
spaces from instance init to realize.
Does anyon
Hi all,
This email follows on from my investigation of intermittent Travis-CI failures in
make check's device-introspect test when trying to add the patch at
https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg06093.html to my last
qemu-sparc pull request.
The patch itself seems fairly
12 matches
Mail list logo
