[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: Mon, 05 Sep 2011 12:28:50 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 09/05/2011 12:22 PM, Edgar E. Iglesias wrote:
>  (real hardware can query a line at any time, yes?)

IMO, the "query" is just an upside-down way of thinking of it.

What happens is, you change some state, and the state drives changes through
a logic path towards new state that picks up the updated value etc etc.
Quering is like going (for bus accesses): OK, here's my VGA framebuffer
address, lets do a get back through the bus and see what the CPU wants to
write to this location?

According to the query view, you would add state to the memory regions so
that an MMIO device only gets a xxx_access call, and does a query back to
the core to figure out what's going on. Possible? I'm sure it is. Correct?
who knows.

There's no difference really. Consider reading the 'data' parameter a query.

With qemu_irq, there is a difference, because the line level is valid at all times, not just when the edge takes place (for memory, the data lines are only valid during the transaction).

But IMO, a very upside-down way of thinking of it.

Query is needed when a line is masked internally, or when a device is hot-plugged.

We can work around masking by caching the level in the device even though the line is masked, and querying the cache when the line is unmasked, but that is artificial, and requires live-migrating the cache (which isn't true state). We can't work around the hotplug case.

error compiling committee.c: too many arguments to function

reply via email to

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