[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: |
Wed, 18 May 2011 18:42:12 +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-18 18:33, Anthony Liguori wrote:
> On 05/18/2011 10:23 AM, Avi Kivity wrote:
>>> The tricky part is wiring this up efficiently for TCG, ie. in QEMU's
>>> softmmu. I played with passing the issuing CPUState (or NULL for
>>> devices) down the MMIO handler chain. Not totally beautiful as
>>> decentralized dispatching was still required, but at least only
>>> moderately invasive. Maybe your API allows for cleaning up the
>>> management and dispatching part, need to rethink...
>>
>> My suggestion is opposite - have a different MemoryRegion for each (e.g.
>> CPUState::memory). Then the TLBs will resolve to a different ram_addr_t
>> for the same physical address, for the local APIC range.
>
> I don't understand the different ram_addr_t part.
>
> The TLB should dispatch to a per-CPU dispatch table. The per-CPU should
> dispatch almost everything to a global dispatch table.
>
> The global dispatch table is the chipset (Northbridge/Southbridge).
>
> The chipset can then dispatch to individual busses which can then
> further dispatch as appropriate.
>
> Overlapping regions can be handled differently at each level. For
> instance, if a PCI device registers an IO region to the same location as
> the APIC, the APIC always wins because the PCI bus will never see the
> access.
>
> You cannot do this properly with a single dispatch table because the
> behavior depends on where in the hierarchy the I/O is being handled.
Ah, now I remember why I did not follow that path: Not invasiveness, but
performance concerns. I assume TLB refills have their share in TCG
performance, and adding another lookup layer, probably for every target,
will be measurable. I was wondering if that is worth the, granted,
cleaner design.
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, 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
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API,
Jan Kiszka <=
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18
Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Avi Kivity, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18
- Re: [Qemu-devel] [RFC] Memory API, Jan Kiszka, 2011/05/18
Re: [Qemu-devel] [RFC] Memory API, Anthony Liguori, 2011/05/18