[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: |
Thu, 19 May 2011 15:47:19 +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 15:44, Anthony Liguori wrote:
> On 05/19/2011 04:10 AM, Avi Kivity wrote:
>> On 05/19/2011 12:08 PM, Gleb Natapov wrote:
>>> On Wed, May 18, 2011 at 06:42:14PM +0300, Avi Kivity wrote:
>>>> On 05/18/2011 06:36 PM, Jan Kiszka wrote:
>>>>>>
>>>>>> We need to head for the more hardware-like approach. What happens
>>> when
>>>>>> you program overlapping BARs? I imagine the result is
>>>>>> implementation-defined, but ends up with one region decoded in
>>>>>> preference to the other. There is simply no way to reject an
>>>>>> overlapping mapping.
>>>>>
>>>>> But there is also now simple way to allow them. At least not without
>>>>> exposing control about their ordering AND allowing to hook up managing
>>>>> code (e.g. of the PCI bridge or the chipset) that controls
>>> registrations.
>>>>
>>>> What about memory_region_add_subregion(..., int priority) as I
>>>> suggested in another message?
>>> Haven't saw another message yet, but how caller knows about priority?
>>
>> The caller is emulating some hub or router and should decide on priority
>> like real hardware.
>>
>> For example, piix gives higher priority to the vga window over RAM.
>
> Well......
>
> The i440fx may direct VGA accesses to RAM depending on the SMM
> registers. By the time the PIIX gets the I/O request, we're past the
> memory controller.
>
> This is my biggest concern about this whole notion of "priority". These
> sort of issues are not dealt with by a simple z-ordering. There is
> logic in each component that may be arbitrarily complex.
>
> We're going to end up having to dynamically change the "priority" based
> how registers are programmed. But priorities are relative so it's
> unclear to me how the I440FX would prioritize RAM over dispatch to PIIX
> (for VGA, for instance).
But creating an extra RAM window region with higher priority than the
underlying mappings.
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, Avi Kivity, 2011/05/20
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/20
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/20
- 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 <=
- 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
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Edgar E. Iglesias, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Peter Maydell, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18