[Top][All Lists]
[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: |
Fri, 20 May 2011 17:59:33 +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-20 17:33, Anthony Liguori wrote:
> On 05/20/2011 04:01 AM, Avi Kivity wrote:
>> On 05/19/2011 07:32 PM, Anthony Liguori wrote:
>>>> 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).
>>
>> VGA will override RAM.
>>
>> Memory controller
>> |
>> +-- RAM container (prio 0)
>> |
>> +-- PCI container (prio 1)
>> |
>> +--- vga window
>
> Unless the RAM controller increases it's priority, right? That's how
> you would implement SMM, by doing priority++?
>
> But if you have:
>
> Memory controller
> |
> +-- RAM container (prio 0)
> |
> +-- PCI container (prio 1)
> |
> +-- PCI-X container (prio 2)
> |
> +--- vga window
>
> Now you need to do priority = 3?
>
> Jan had mentioned previously about registering a new temporary window.
> I assume the registration always gets highest_priority++, or do you have
> to explicitly specify that PCI container gets priority=1?
The latter.
And I really prefer to have this explicit over deriving the priority
from the registration order. That's way too fragile/unhandy. If you
decide to replace a region of lower priority later on, you need to
reregister everything at that level.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [RFC] Memory API, (continued)
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/20
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/20
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/20
- Re: [Qemu-devel] [RFC] Memory API,
Jan Kiszka <=
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/22
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/22
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19