Zhang, Xiantao wrote:
>>> struct kvm_vcpu {
>>> struct kvm *kvm;
>>> struct preempt_notifier preempt_notifier;
>>> int vcpu_id;
>>> struct mutex mutex;
>>> int cpu;
>>> - u64 host_tsc;
>>> struct kvm_run *run;
>>> int interrupt_window_open;
>> This one should go to arch.
>>> int guest_mode;
>>> unsigned long requests;
>>> unsigned long irq_summary; /* bit vector: 1 per word in
>>> irq_pending */ DECLARE_BITMAP(irq_pending, KVM_NR_INTERRUPTS);
>> Both irq related ones too please.
>
> I can't understand about it, doesn't s390 need userspace to transfer
> interrupts into kvm module? or other approaches? T
> If need, we had better follow existing infrastructure of KVM, or it may
> introduce unnecessary for most archs.
> Please don't forget that we are in KVM world :)
We do need to inject interrupts from userspace too. But our I/O
architecture is completely different from other architectures.
Interrupts may be floating (that is, for all cpus) or for a specific
cpu. They may be external interrupts (64k different interrupt
numbers), or I/O interrupts (16.7 million different interrupt
numbers). And interrupts come in different interrupt subclasses which
can be masked independent. In short: we're very very different on
interrupts, and above fields in vcpu don't work for us. That is why
the code that deals with interrupts along with the data structures in
kvm_vcpu that deal with interrupts need to be architecture dependent.
Carsten
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
