Re: [PATCH][Resend] Split kvm_vcpu to support new archs.

[Carsten Otte <cotte-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>]

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/