On 08/21/2009 09:16 PM, Gleb Natapov wrote:
On Mon, Aug 17, 2009 at 12:35:47PM +0300, Avi Kivity wrote:
On 08/13/2009 08:19 PM, Gleb Natapov wrote:
This removes assumptions that max GSIs is smaller than number of pins.
Sharing is tracked on pin level not GSI level.
Signed-off-by: Gleb Natapov<gleb@xxxxxxxxxx>
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index b17d845..4c15bdd 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -413,7 +413,6 @@ struct kvm_arch{
gpa_t ept_identity_map_addr;
unsigned long irq_sources_bitmap;
- unsigned long irq_states[KVM_IOAPIC_NUM_PINS];
u64 vm_init_tsc;
};
diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
index 7d6058a..c025a23 100644
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -71,6 +71,7 @@ struct kvm_pic {
int output; /* intr from master PIC */
struct kvm_io_device dev;
void (*ack_notifier)(void *opaque, int irq);
+ unsigned long irq_states[16];
};
I think it's cleaner to move this into the routing table to avoid
duplication. Currently there is no object which is unique to a gsi,
but after your array patch, it can be placed next to the hlist_head.
The problem is that at this level it is not known if GSI is MSI or not.
Current code dials with this by arbitrary assuming that GSI is MSI if it
is greater then KVM_IOAPIC_NUM_PINS, but this is not enforced when
routing table is installed and userspace is free to use any GSI as MSI.
Of cause this problem would not exist if MSIs were not linked to GSIs
in the first place.
Does msi actually care about the states? I don't think it does.
The code duplication is very small (one line of code) and logically it
is more correct to track duplications at irqchip level. Theoretically
GSI may be shared when PIC is used and not shared when IOAPIC is used.
No, it's more correct at the GSI level, since all interrupt lines
connected to one GSI are shared.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
