Re: [RFC v5 00/86] Memory API

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

 



On 2011-07-21 10:37, Avi Kivity wrote:
> On 07/21/2011 12:43 AM, Jan Kiszka wrote:
>> On 2011-07-20 19:43, Avi Kivity wrote:
>> >  On 07/20/2011 08:41 PM, Jan Kiszka wrote:
>> >>  On 2011-07-20 18:49, Avi Kivity wrote:
>> >>  >   New in this version:
>> >>  >     - more mindless conversions; I believe there are no longer any
>> >>  destructive
>> >>  >       operations in the tree (IO_MEM_UNASSIGNED)
>> >>  >     - fix memory map generation bug (patch 13)
>> >>  >     - proper 440FX PAM/SMRAM and PCI holes
>> >>  >
>> >>
>> >>  This on top fixes standard VGA dirty logging:
>> >
>> >  Both work for me without any patches.
>>
>> Impossible! ;)
>>
>> VGA frame buffer cannot work as no one enabled dirty logging for that
>> range so far. Try -vga std with vga=0x314 in the guest.
>>
> 
> Right, actually booting into X showed that.  But I don't understand how
> it worked before - my patches only change how vga_start_dirty_log() is
> implemented, not when/where it is called.

To answer this question as well: You dropped all the vga_start_dirty_log
originally performed during PCI mapping.

> 
> 
>> >
>> >  Maybe the F15 window manager is polling the display?
>> >
>>
>> Only if that continuously enforces a full window refresh.
> 
> Turned out to be a tester issue.
> 
>> As expected, there were dirty logging issues around removing a
>> subregion on cirrus bank pointer updates. This makes linear vram
>> mappings work again:
> 
> Please sign off patches!

Always - once they are done.

> 
>> diff --git a/memory.c b/memory.c
>> index a8d4295..14fac8a 100644
>> --- a/memory.c
>> +++ b/memory.c
>> @@ -1093,9 +1093,26 @@ void
>> memory_region_add_subregion_overlap(MemoryRegion *mr,
>>   void memory_region_del_subregion(MemoryRegion *mr,
>>                                    MemoryRegion *subregion)
>>   {
>> +    MemoryRegion *target_region;
>> +    ram_addr_t base, offs;
>> +
>>       assert(subregion->parent == mr);
>>       subregion->parent = NULL;
>>       QTAILQ_REMOVE(&mr->subregions, subregion, subregions_link);
>> +
>> +    if (subregion->alias) {
>> +        base = subregion->alias_offset;
>> +        target_region = subregion->alias;
>> +    } else {
>> +        base = 0;
>> +        target_region = subregion;
>> +    }
>> +    if (target_region->dirty_log_mask) {
>> +        for (offs = 0; offs<  subregion->size; offs +=
>> TARGET_PAGE_SIZE) {
>> +            memory_region_set_dirty(target_region, base + offs);
>> +        }
>> +    }
>> +
> 
> The subregion may be partially or fully obstructed.  This needs to be
> done at the FlatRange level (as_memory_range_del(), most likely).

Makes some sense. I even wonder if this isn't a KVM deficit and should
be handled there when a logged region is unmapped.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux