qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Memory API


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Thu, 19 May 2011 11:09:17 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10

On 05/18/2011 10:10 PM, Anthony Liguori wrote:
On 05/18/2011 10:30 AM, Jan Kiszka wrote:
On 2011-05-18 17:17, Peter Maydell wrote:
On 18 May 2011 16:11, Jan Kiszka<address@hidden>  wrote:
On 2011-05-18 16:36, Avi Kivity wrote:
There is nothing we can do with a return code. You can't fail an mmio
that causes overlapping physical memory map.

We must fail such requests to make progress with the API. That may
happen either on caller side or in cpu_register_memory_region itself
(hwerror). Otherwise the new API will just be a shiny new facade for on
old and still fragile building.

If we don't allow overlapping regions, then how do you implement
things like "on startup board maps ROM into lower addresses
over top of devices, but later it is unmapped and you can see
the underlying devices" ? (You can't currently do this AFAIK,
and it would be nice if the new API supported it.)

Right, we can't do this properly, and that's why the attempt if the
i440fx chipset model is so horribly broken ATM.

Just allowing overlapping does not solve this problem either. It does
not specify what region is on top and what is below (even worse if
multiple regions overlap at the place).

We need some managing instance here, and that is e.g. the chipset that
provide control over the overlap in reality. It could hook up a
PhysMemClient to receive and redirect updates to subregions, or only
allow to register them in disabled state.

I think that gets ugly pretty fast. The way this works IRL is that all I/O dispatches pass through the chipset. You literally need something as simple as:

static void i440fx_io_intercept(void *opaque, uint64_t addr, uint32_t value, int size, MemRegion *next)
{
    I440FX *s = opaque;

    if (range_overlaps(addr, size, PAM_REGION)) {
        ...
    } else {
        dispatch_io(next, addr, value, size);
    }
}

There's no need for an explicit intercept mechanism if you make multiple levels have their own dispatch tables and register progressively larger regions. In fact....

You really don't need to register 90% of the time. In the case of a PC with i440fx, it's really quite simple:

if an I/O is to the APIC page,
   it's handled by the APIC
elif the I/O is in ROM regions:
   if PAM RE or WE
      redirect to RAM appropriately
   else:
      send to ROMs
elif the I/O is in the PCI windows:
   send to the PCI bus
else:
   send to the PIIX3


Memory regions do the exact same thing, except at registration time. The nested if/elif/else tree is captured in the nested region tree.

--
error compiling committee.c: too many arguments to function




reply via email to

[Prev in Thread] Current Thread [Next in Thread]