Should we move kvm_vcpu_ioctl_interrupt to arch?

Should we move kvm_vcpu_ioctl_interrupt to arch?

[Zhang, Xiantao]

Hi, Avi
	Since IA64's irqchip is always in kernel side, so we don't need
kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to arch?
Otherwise, we have to define two unnecessary fields(irq_summary and
irq_pending) for vcpu structure for compile pass.
Xiantao

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Should we move kvm_vcpu_ioctl_interrupt to arch?

[Carsten Otte]

Zhang, Xiantao wrote:
> 	Since IA64's irqchip is always in kernel side, so we don't need
> kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to arch?
> Otherwise, we have to define two unnecessary fields(irq_summary and
> irq_pending) for vcpu structure for compile pass.
We don't have an irqchip at all. Nevertheless we have the need to 
inject interrupts from userspace. How does the in-kernel irqchip get 
triggered to present an interruption from userland?

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Should we move kvm_vcpu_ioctl_interrupt to arch?

[Zhang, Xiantao]

Carsten Otte wrote:KVM_IRQ_LINE
> Zhang, Xiantao wrote:
>> 	Since IA64's irqchip is always in kernel side, so we don't need
>> kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to
>> arch? Otherwise, we have to define two unnecessary
>> fields(irq_summary and irq_pending) for vcpu structure for compile
>> pass. 
> We don't have an irqchip at all. Nevertheless we have the need to
> inject interrupts from userspace. How does the in-kernel irqchip get
> triggered to present an interruption from userland?

You mean you also need these two fields to hold irqs ? 

If in-kernel irqchip works,  all irqs from userland may transfer to
kernel through another path. You can reference KVM_IRQ_LINE vm ioctl for
that.  

If you don't need these two fields as well, we can use CONFIG_X86 macro
to comment out them in common code instead.

Xiantao

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Should we move kvm_vcpu_ioctl_interrupt to arch?

[Carsten Otte]

Zhang, Xiantao wrote:
> You mean you also need these two fields to hold irqs ? 
No we don't. I think they can go to x86.



-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4

Re: Should we move kvm_vcpu_ioctl_interrupt to arch?

[Avi Kivity]

Zhang, Xiantao wrote:
> Hi, Avi
> 	Since IA64's irqchip is always in kernel side, so we don't need
> kvm_vcpu_ioctl_interrupt for irq delivery. Should we moved it to arch?
> Otherwise, we have to define two unnecessary fields(irq_summary and
> irq_pending) for vcpu structure for compile pass.
>   

Yes, it can be x86 specific (or arch specific if somebody else wants it).


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4