[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 16:20: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 16:15, Anthony Liguori wrote:
> On 05/19/2011 08:53 AM, Avi Kivity wrote:
>> On 05/19/2011 04:49 PM, Anthony Liguori wrote:
>>> On 05/19/2011 08:30 AM, Avi Kivity wrote:
>>>> On 05/19/2011 04:26 PM, Jan Kiszka wrote:
>>>>> On 2011-05-19 15:07, Avi Kivity wrote:
>>>
>>>>> And when introducing hierarchical registration, we will have to go
>>>>> through all of this once again. Plus the API may have to be changed
>>>>> again if it does not fulfill all requirements of the hierarchical
>>>>> region
>>>>> management. And we have no proof that it allows an efficient core
>>>>> implementation.
>>>>
>>>> This API *is* hierarchical registration. v2 will (hopefully) prove that
>>>> it can be done efficiently.
>>>
>>> We also need hierarchical dispatch. Priorities are just a weak attempt
>>> to emulate hierarchical dispatch but I don't think there's an
>>> improvement over a single dispatch table.
>>>
>>> Hierarchical dispatch is simpler. You just need a simple list at each
>>> bus.
>>>
>>
>> The API itself says nothing about whether the hierarchy is evaluated at
>> run-time or registration time.
>
> Except for priorities.
>
> If you've got a hierarchy like:
>
> - CPU:0
> - i440fx:1
> - PIIX3:2
> - ISA:3
> - DeviceA
> - PCI:2
> - DeviceB
>
> In your model, the default priorities are as shown, but nothing stops
> DeviceB from registering with a priority of 0 which means it can
> intercept accesses that would normally go to the i440fx.
Priorities would be local, so the normal tree would look like this:
- CPU:0
- i440fx:0
- PIIX3:0
- DeviceA
- PCI-DeviceB:0
If the i440fx would like to map something different over DeviceA (or
parts of it), it would create a region of prio 1 or higher.
The same would happen at CPU-level with SMRAM when SMM is entered.
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, 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, Anthony Liguori, 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 <=
- 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, 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, Jan Kiszka, 2011/05/19
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/19