Il 28/02/2014 05:06, Gabriel L. Somlo ha scritto: > +NOTE: For each level-triggered interrupt managed by a virtual ioapic, > +the guest OS may set a polarity value (bit 13 of each corresponding I/O > +redirection table register). The polarity bit defines the relationship > +between an irq line's logical state (active/asserted = 1, inactive = 0) > +and its physical state (high = 1, low = 0). When the polarity bit is 0 > +(ActiveHigh), logical and physical states are matched (active == high == 1, > +inactive == low == 0). When polarity is set to 1 (ActiveLow), logical and > +physical state are opposites (logical == !physical). Typically, guests are > +expected to use the same polarity across all level-triggered interrupts, > +as directed by ACPI. Historically, both KVM and QEMU have accumulated a > +significant number of optimizations based on the hard-coded assumption > +that polarity will always be set to ActiveHigh. When interfacing with KVM, > +QEMU will use the ActiveHigh convention for all level-triggered irqs, > +regardless of how the guest OS has configured the polarity bits in the > +ioapic registers. As such, KVM must also ignore these bits, and always act > +as if the logical and physical states of an irq line exactly match each > +other (i.e., follow the ActiveHigh convention regardless of polarity). > +
Instead of this, I'm adding the following to the KVM_IRQ_LINE ioctl: +On real hardware, interrupt pins can be active-low or active-high. This +does not matter for the level field of struct kvm_irq_level: 1 always +means active (asserted), 0 means inactive (deasserted). + +x86 allows the operating system to program the interrupt polarity +(active-low/active-high) for level-triggered interrupts, and KVM used +to consider the polarity. However, due to bitrot in the handling of +active-low interrupts, the above convention is now valid on x86 too. +This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED. Userspace +should not present interrupts to the guest as active-low unless this +capability is present (or unless it is not using the in-kernel irqchip, +of course). and applying the patch to kvm/queue. Paolo
