[Top][All Lists]

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

Re: [kvm-devel] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock +

From: Avi Kivity
Subject: Re: [kvm-devel] [Qemu-devel] [PATCH] [RFC] Fix time drift of rtc clock + general support
Date: Mon, 24 Mar 2008 15:56:19 +0200
User-agent: Thunderbird (X11/20080226)

Paul Brook wrote:
On Monday 24 March 2008, Avi Kivity wrote:
Paul Brook wrote:
On Sunday 23 March 2008, Dor Laor wrote:
--- a/qemu/hw/irq.c
+++ b/qemu/hw/irq.c
@@ -30,6 +30,8 @@ struct IRQState {
     int n;

+uint32_t qemu_irq_acked[NR_IRQ_WORDS];
This is absolute rubbish. The whole point of the IRQ framework is that it
doesn't assume a single flat IRQ controller.
x86 does have a single irq space (even when using cascaded pics or
multiple ioapics), called gsi (for generalized system interrupt, or
something).  It is possible to enumerate all irqs on all platforms that
have a finite number of them.

Sure, it's possible to enumerate all the possible IRQ inputs (it's effectively the same as enumerating all the IRQ sources). It's not possible to say anything particularly useful about that enumeration though. It's not uncommon for interrupts to be connected to GPIO pins, be inverted, or have interrupt routings that change dynamically.

Right, but...

It may be better though to identify an irq by a (controller_id,
irq_line) pair instead.

That's what qemu_irq is for. Anything else is IMHO wrong.

In the case of a kernel virtualization module (like kqemu of kvm) that is able to handle interrupt injection, qemu_irq is not sufficient since it is not visible to the kernel. We need some serialization that can pass the user/kernel boundary. For x86 gsi is a satisfactory serialization.

Even for a pure qemu solution, qemu_irq is difficult to work with. For the x86 case, we know which vector was successfully injected, and we need to work out which qemu_irq caused it. This is not deterministic in the general case (since several irq lines can cause the same vector to be injected, and since the irq->vector mapping can change), so any solution will involve heuristics.

error compiling committee.c: too many arguments to function

reply via email to

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