qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Memory API


From: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Thu, 19 May 2011 18:50: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-05-19 18:38, Anthony Liguori wrote:
> On 05/19/2011 11:35 AM, Jan Kiszka wrote:
>> On 2011-05-19 18:32, Anthony Liguori wrote:
>>> On 05/19/2011 09:40 AM, Avi Kivity wrote:
>>>> On 05/19/2011 05:37 PM, Anthony Liguori wrote:
>>>>>
>>>>> So.... do you do:
>>>>>
>>>>> isa_register_region(ISABus *bus, MemoryRegion *mr, int priority)
>>>>> {
>>>>> chipset_register_region(bus->chipset, mr, priority + 1);
>>>>> }
>>>>>
>>>>> I don't really understand how you can fold everything into one table
>>>>> and not allow devices to override their parents using priorities.
>>>>
>>>> Think of how a window manager folds windows with priorities onto a flat
>>>> framebuffer.
>>>>
>>>> You do a depth-first walk of the tree. For each child list, you iterate
>>>> it from the lowest to highest priority, allowing later subregions
>>>> override earlier subregions.
>>>>
>>>
>>> Okay, but this doesn't explain how you'll let RAM override the VGA
>>> mapping since RAM is not represented in the same child list as VGA (RAM
>>> is a child of the PMC whereas VGA is a child of ISA/PCI, both of which
>>> are at least one level removed from the PMC).
>>
>> You can always create a new memory region with higher priority, pointing
>> to the RAM window you want to have above VGA. That's what we do today as
>> well, just with different effects on the internal representation.
> 
> But then we're no better than we are today.  I thought the whole point 
> of this thread of discussion was to allow overlapping I/O regions to be 
> handled in a better way than we do today?

We would be much better than today. Today some broken magic is applied
to account for the fact that overlapping registrations destroy the
information below. In the future, that will be preserved, and removing
the overlap will restore previous mappings - or even those which were
modified in the meantime.

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]