On 12 December 2011 17:40, Avi Kivity wrote:
> On 12/12/2011 06:31 PM, Peter Maydell wrote:
>> I think with an in-kernel GIC model you'd only need to be able to set
>> one of the (256 including internal-to-the-CPU inputs) GIC input lines;
>> the GIC itself then connects directly to the vcpu IRQ an
On Dec 12, 2011, at 12:40 PM, Avi Kivity wrote:
> On 12/12/2011 06:31 PM, Peter Maydell wrote:
>> On 11 December 2011 23:01, Jan Kiszka wrote:
>>> Enabling in-kernel irqchips usually means "switching worlds". So the
>>> semantics of these particular IRQ inject interface details may change
>>> wi
On 12/12/2011 06:31 PM, Peter Maydell wrote:
> On 11 December 2011 23:01, Jan Kiszka wrote:
> > Enabling in-kernel irqchips usually means "switching worlds". So the
> > semantics of these particular IRQ inject interface details may change
> > without breaking anything.
> >
> > However, things migh
On 11 December 2011 23:01, Jan Kiszka wrote:
> Enabling in-kernel irqchips usually means "switching worlds". So the
> semantics of these particular IRQ inject interface details may change
> without breaking anything.
>
> However, things might look different if there will be a need to inject
> also
On 12/12/2011 05:11 PM, Christoffer Dall wrote:
> >> If I should re-use the existing one, should I simply move it outside
> >> of __KVM_HAVE_IOAPIC?
> >
> > Protect it with __KVM_HAVE_IRQ_LINE so we don't leak unused tracepoints
> > for other archs.
> >
>
> ok. I used to be scared of touching your
On Mon, Dec 12, 2011 at 9:50 AM, Avi Kivity wrote:
> On 12/12/2011 04:38 PM, Christoffer Dall wrote:
>> >
>> > Why don't they match? The assignment of lines to actual pins differs,
>> > but essentially it's the same thing (otherwise we'd use a different ioctl).
>> >
>>
>> because there is no noti
On 12/12/2011 04:38 PM, Christoffer Dall wrote:
> >
> > Why don't they match? The assignment of lines to actual pins differs,
> > but essentially it's the same thing (otherwise we'd use a different ioctl).
> >
>
> because there is no notion of gsi and irq_source_id on ARM.
gsi = number of irq l
On Mon, Dec 12, 2011 at 8:28 AM, Avi Kivity wrote:
> On 12/11/2011 12:24 PM, Christoffer Dall wrote:
>> Userspace can inject IRQs and FIQs through the KVM_IRQ_LINE VM ioctl.
>> This ioctl is used since the sematics are in fact two lines that can be
>> either raised or lowered on the VCPU - the IRQ
On Mon, Dec 12, 2011 at 6:06 AM, Marc Zyngier wrote:
> On 11/12/11 20:07, Christoffer Dall wrote:
>> On Dec 11, 2011, at 2:48 PM, Peter Maydell wrote:
>>
>>> On 11 December 2011 19:30, Christoffer Dall
>>> wrote:
On Sun, Dec 11, 2011 at 11:03 AM, Peter Maydell
wrote:
> Removing th
On 11/12/11 20:07, Christoffer Dall wrote:
> On Dec 11, 2011, at 2:48 PM, Peter Maydell wrote:
>
>> On 11 December 2011 19:30, Christoffer Dall
>> wrote:
>>> On Sun, Dec 11, 2011 at 11:03 AM, Peter Maydell
>>> wrote:
Removing the mask would be wrong since the irq field here
is encodin
On 11.12.2011, at 20:48, Peter Maydell wrote:
> On 11 December 2011 19:30, Christoffer Dall
> wrote:
>> On Sun, Dec 11, 2011 at 11:03 AM, Peter Maydell
>> wrote:
>>> Removing the mask would be wrong since the irq field here
>>> is encoding both cpu number and irq-vs-fiq. The default is
>>> jus
On 2011-12-11 23:53, Christoffer Dall wrote:
> On Sun, Dec 11, 2011 at 5:35 PM, Peter Maydell
> wrote:
>> On 11 December 2011 22:12, Peter Maydell wrote:
>>> (Actually what would be clearest would be if the ioctl took the
>>> (interrupt-target, interrupt-line-for-that-target, value-of-line)
>>>
On Sun, Dec 11, 2011 at 5:35 PM, Peter Maydell wrote:
> On 11 December 2011 22:12, Peter Maydell wrote:
>> (Actually what would be clearest would be if the ioctl took the
>> (interrupt-target, interrupt-line-for-that-target, value-of-line)
>> tuple as three separate values rather than encoding tw
On 11 December 2011 22:12, Peter Maydell wrote:
> (Actually what would be clearest would be if the ioctl took the
> (interrupt-target, interrupt-line-for-that-target, value-of-line)
> tuple as three separate values rather than encoding two of them into
> a single integer, but I assume there's a re
On 11 December 2011 21:36, Christoffer Dall
wrote:
> On Sun, Dec 11, 2011 at 3:25 PM, Peter Maydell
> wrote:
>> On 11 December 2011 20:07, Christoffer Dall
>> wrote:
>>> Well, if it was just "irq & 1", then I hear you, but it would be "(irq
>>> >> cpu_idx) & 1" which I don't think is more clear
On Sun, Dec 11, 2011 at 3:25 PM, Peter Maydell wrote:
> On 11 December 2011 20:07, Christoffer Dall
> wrote:
>> Well, if it was just "irq & 1", then I hear you, but it would be "(irq
>> >> cpu_idx) & 1" which I don't think is more clear.
>
> Er, what? The fields are [31..1] CPU index and [0] irqt
On 11 December 2011 20:07, Christoffer Dall
wrote:
> Well, if it was just "irq & 1", then I hear you, but it would be "(irq
> >> cpu_idx) & 1" which I don't think is more clear.
Er, what? The fields are [31..1] CPU index and [0] irqtype,
right? So what you have now is:
vcpu_idx = irq_level->
On Dec 11, 2011, at 2:48 PM, Peter Maydell wrote:
> On 11 December 2011 19:30, Christoffer Dall
> wrote:
>> On Sun, Dec 11, 2011 at 11:03 AM, Peter Maydell
>> wrote:
>>> Removing the mask would be wrong since the irq field here
>>> is encoding both cpu number and irq-vs-fiq. The default is
>>>
18 matches
Mail list logo
