[Top][All Lists]
[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 16:42:27 +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 16:37, Michael S. Tsirkin wrote:
> On Wed, Jul 20, 2011 at 05:32:54PM +0300, Avi Kivity wrote:
>> On 07/20/2011 04:57 PM, Jan Kiszka wrote:
>>> 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 don't see this here, will retest.
>>
>>> 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)?
>>
>> There should be no ordering issue at all.
>>
>> If you do a memory_region_set_log() immediately after
>> memory_region_init_ram(), then as soon as the framebuffer is added
>> to the memory hierarchy, it will have logging enabled (or any
>> aliases of the framebuffer).
>
> Still, I think we should specify logging on/off when region is created,
> and avoid APIs that tweak dirty logging.
> I don't think there's actual need for device to enable/disable
> logging. What devices seem to need, instead, is enable/disable a region
> through a back channel.
Dropping memory_region_set_log would allow to drop the corresponding
client callbacks as well. However, we apparently need enable/disable
semantic for the crazy vmware vga. I tried without but failed. But we
could map it for this single user on delete/recreate (like I did with my
original patches).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, (continued)
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/19
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Jan Kiszka, 2011/07/19
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Jan Kiszka, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Jan Kiszka, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Jan Kiszka, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Michael S. Tsirkin, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API,
Jan Kiszka <=
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Jan Kiszka, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Jan Kiszka, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Michael S. Tsirkin, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20
- Re: [Qemu-devel] [RFC v4 00/58] Memory API, Michael S. Tsirkin, 2011/07/20
Re: [Qemu-devel] [RFC v4 00/58] Memory API, Avi Kivity, 2011/07/20