[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] pc: Clean up PIC-to-APIC IRQ path

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

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

reply via email to

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