[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 14:02:31 +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 13:58, Gleb Natapov wrote:
> On Thu, May 19, 2011 at 01:57:15PM +0200, Jan Kiszka wrote:
>> On 2011-05-19 13:54, Gleb Natapov wrote:
>>> On Thu, May 19, 2011 at 02:44:29PM +0300, Avi Kivity wrote:
>>>> On 05/19/2011 12:14 PM, Gleb Natapov wrote:
>>>>> On Thu, May 19, 2011 at 12:10:38PM +0300, 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.
>>>>>>
>>>>> Hmm, but if a caller of the memory_region_add_subregion() function is a
>>>>> device itself how does it know about chipset priorities. All it wants to
>>>>> tell to the system is that it is ready to handle mmio access in this phys
>>>>> range, but chipset may decide to forward those accesses elsewhere.
>>>>
>>>> In this case the device would call a chipset function, passing the
>>>> memory region as a parameter, and the chipset would call
>>>> m_r_add_subregion().
>>> But then chipset can resolve all overlapping by itself and register only
>>> regions that are actually accessible by a guest software. Also there are
>>> devices that on some architectures are accessed through a chipset and on
>>> other they resides directly on a system bus. If they will need to call
>>> different memory registration api depending on how they are instantiated
>>> the code can become messy.
>>
>> Devices shall register their regions with the bus. Every device is on
>> some bus, so that's not a problem. And we can then provide registration
>> handlers at bus level that either implement specific logic or just
>> forward the request to the next hierarchy level (default handler).
>>
> Yes, I agree with that. I just don't see the need for "priority" parameter
> in this model.
"Controlled" overlapping can indeed simplify the implementation of a
dispatcher that wants to flip between putting some region logically over
an existing, possibly complex layout and disabling this overlay. For
that purpose, the overlay requires a high prio than what is below (using
a default priority).
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/19
- Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Gleb Natapov, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API,
Jan Kiszka <=
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 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, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 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, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/19