|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path |
Date: | Sun, 04 Sep 2011 18:34:00 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 |
On 09/04/2011 06:19 PM, Anthony Liguori wrote:
Yes, and the memory API is complicated and invasive :-) But it's worth it at the end of the day (although I think it could be simplified at the expensive of not allowing as much flattening).(we should have spent a few hours at kf2011 to convince you that this is impossible)I don't mean for RAM, but for device I/O.
It's impossible to make the distinction. A piece of RAM can overlay an mmio region and split it in two, or an mmio region can split a RAM region. This means the machinery cannot consider the region type anyway.
Instead of implementing it_shift in the core API, you could implement it_shift by having a device that takes an input MemoryRegion and an output MemoryRegion and implements the it_shift logic.
We could, but that imposes a burden on users to find that device and glue it to the memory API. I'm not after a mean and lean API, I'm after something that is easy enough to use that people manage to get device models that work.
I think endianness could also be handled this way too.
On some archs, endianness can find itself in RAM, so we need complete control. And again, I don't want users gluing stuff together the wrong way, I want them using a simple interface.
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |