qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycl


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 10/10] qdev: fix create in place obj's life cycle problem
Date: Wed, 05 Sep 2012 13:11:49 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-09-05 12:53, Avi Kivity wrote:
> On 09/05/2012 01:36 PM, Jan Kiszka wrote:
>>>
>>> My current preference is MemoryRegionOps::ref(MemoryRegion *mr) (and a
>>> corresponding unref), which has the following requirements:
>>>
>>> - if the refcount is nonzero, MemoryRegion::opaque is safe to use
>>> - if the refcount is nonzero, the MemoryRegion itself is stable.
>>
>> The second point means that the memory subsystem will cache the region
>> state and apply changes only after leaving a handler that performed them?
> 
> No.  I/O callbacks may be called after a region has been disabled.
> 
> I guess we can restrict this to converted regions, so we don't introduce
> regressions.

s/can/have to/. This property change will require some special care,
hopefully mostly at the memory layer. A simple scenario from recent patches:

    if (<enable>) {
        memory_region_set_address(&s->pm_io, pm_io_base);
        memory_region_set_enabled(&s->pm_io, true);
    } else {
        memory_region_set_enabled(&s->pm_io, false);
    }

We will have to ensure that set_enabled(..., true) will never cause a
dispatch using an outdated base address.

I think discussing semantics and usage patterns of the new memory API -
outside of the BQL - will be the next big topic. ;)

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



reply via email to

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