qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC v4 00/58] Memory API


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC v4 00/58] Memory API
Date: Wed, 20 Jul 2011 15:57:32 +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 2011-07-20 13:57, Avi Kivity wrote:
> On 07/20/2011 02:43 PM, Jan Kiszka wrote:
>> On 2011-07-20 10:13, Avi Kivity wrote:
>>>  On 07/19/2011 08:30 PM, Jan Kiszka wrote:
>>>>>   Rebasing is already not so fun for me with 78 patches and counting.
>>>>>   Let's drop yours and focus of getting mine in shape, since it's a 
>>>>> superset.
>>>>
>>>>  The patches series are widely orthogonal except for both killing the
>>>>  obsolete start/stop logging logic.
>>>>
>>>>  But I don't mind rebasing over yours - if something is finally merged at
>>>>  all.
>>>
>>>  If you post patches I'll incorporate them in my patchset.  They're
>>>  available in qemu-kvm.git branch memory-region.
>>
>> Is that branch up-to-date? It spits out tons of debug messages, making
>> it unusable for any test.
>>
> 
> I usually redirect them away.
> 
> I'll move the two patches on top, so it's easy to have git drop them.

Something around dirty logging is still seriously borken: when I boot
with standard or cirrus vga, the screen is not properly updated in
logged modes.

I bet the reason is lacking semantics of
cpu_register_physical_memory_log(..., true), ie. the chance to register
a memory region with logging enabled. We need to explicitly enable it
now via memory_region_set_log, right? Is there any ordering issue to
expect, ie. when can I first call memory_region_set_log (as it issues
the start/stop client callbacks)?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux



reply via email to

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