From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH v3 1/8] ARM: KVM: Initial skeleton to compile KVM support
Date: Sun, 05 Jun 2011 17:18:27 +0300
Message-ID: <4DEB9033.9060109@redhat.com>
References: <20110603150318.17011.82777.stgit@ubuntu> <4DE8FE38.6030405@siemens.com> <4DE90397.5080801@siemens.com> <4DEB74DA.2040909@redhat.com> <4DEB8F22.1020802@web.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Christoffer Dall <cdall@cs.columbia.edu>, catalin.marinas@arm.com,
	android-virt@lists.cs.columbia.edu, s.raho@virtualopensystems.com,
	a.motakis@virtualopensystems.com, c.dall@virtualopensystems.com,
	kvm@vger.kernel.org, a.costa@virtualopensystems.com
To: Jan Kiszka <jan.kiszka@web.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:43934 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1756179Ab1FEOSv (ORCPT <rfc822;kvm@vger.kernel.org>);
	Sun, 5 Jun 2011 10:18:51 -0400
In-Reply-To: <4DEB8F22.1020802@web.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 06/05/2011 05:13 PM, Jan Kiszka wrote:
> On 2011-06-05 14:21, Avi Kivity wrote:
> >  On 06/03/2011 06:53 PM, Jan Kiszka wrote:
> >>  >>   @@ -310,6 +310,7 @@ struct kvm_translation {
> >>  >>    struct kvm_interrupt {
> >>  >>        /* in */
> >>  >>        __u32 irq;
> >>  >>   +    __u8  raise;
> >>  >>    };
> >>  >
> >>  >   This touches an existing ABI and corrupts the definition of
> >>  >   KVM_INTERRUPT IOCTL. The might exist jurisdictions considering this a
> >>  >   capital crime. :)
> >>  >
> >>  >   You rather have to define a new CPU IRQ injection interface that
> >>  >   supports both raising and lowering
> >
> >  This is KVM_IRQ_LINE:
> >
>
> It's so far associated with in-kernel irqchip input pins, not with
> raising CPU IRQs.

It's up to the architecture to define what it's connected to.

Note that with KVM_SET_GSI_ROUTING (bad name for ARM...) we can even 
choose if an irq line is connected to a kernel-emulated interrupt 
controller or to the core's irq input.

> >>  and declare its availability via a
> >>  >   KVM_CAP. Don't forget to make it extensible (flags field) so that
> >>  future
> >>  >   requirements can be added without breaking existing users.
> >>
> >>  Or much easier (this is what PowerPC is doing): Define irq values in a
> >>  way that they include a raise/lower flag.
> >
> >  Much easier and much horribler.
> >
>
> Less horrible than overloading KVM_IRQ_LINE IMHO. The semantics of
> kvm_interrupt::irq are in arch hands anyway.

Something that can be raised or lowered is an irq line.

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