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
11 matches
Mail list logo
