All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Paul Brook <paul@codesourcery.com>,
	qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
	KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] Re: >2 serial ports?
Date: Mon, 22 Mar 2010 11:02:30 +0200	[thread overview]
Message-ID: <4BA73226.6030704@redhat.com> (raw)
In-Reply-To: <4BA72BC5.1020303@msgid.tls.msk.ru>

On 03/22/2010 10:35 AM, Michael Tokarev wrote:
> Paul Brook wrote at Wed, 17 Mar 2010 11:18:09 +0000:
>    
>>> Oh, well, yes, I remember.  qemu is more strict on ISA irq sharing now.
>>>    A bit too strict.
>>>
>>> /me goes dig out a old patch which never made it upstream for some
>>> reason I forgot.  Attached.
>>>        
>> This is wrong. Two devices should never be manipulating the same qemu_irq
>> object.  If you want multiple devices connected to the same IRQ then you need
>> an explicit multiplexer. e.g. arm_timer.c:sp804_set_irq.
>>      
> So... what we have to do here?
>
> I've looked at the mentioned routine, here it is:
>
> /* Merge the IRQs from the two component devices.  */
> static void sp804_set_irq(void *opaque, int irq, int level)
> {
>      sp804_state *s = (sp804_state *)opaque;
>
>      s->level[irq] = level;
>      qemu_set_irq(s->irq, s->level[0] || s->level[1]);
> }
>
> But I know nothing about qemu internals, so don't quite
> understand how to do this in case of serial ports.  I
> see it is tracking two timers and raises the irq level
> if at least one half is raised...  That to say - I've
> got the idea, but how to apply it to serial ports?
>    

Two devices have the same s->irq.  Give each on its own qemu_irq, and 
feed it into a multiplexer that ORs them together and sends the result 
to the interrupt controller's qemu_irq:


S1 ----qemu_irq---->+------+

                     |  mux  +---qemu_irq----->  irq controller

S2 ----qemu_irq---->+------+


(the ascii art will come out all wrong, I know it)

-- 

Do not meddle in the internals of kernels, for they are subtle and quick to panic.


WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	Paul Brook <paul@codesourcery.com>,
	KVM list <kvm@vger.kernel.org>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: >2 serial ports?
Date: Mon, 22 Mar 2010 11:02:30 +0200	[thread overview]
Message-ID: <4BA73226.6030704@redhat.com> (raw)
In-Reply-To: <4BA72BC5.1020303@msgid.tls.msk.ru>

On 03/22/2010 10:35 AM, Michael Tokarev wrote:
> Paul Brook wrote at Wed, 17 Mar 2010 11:18:09 +0000:
>    
>>> Oh, well, yes, I remember.  qemu is more strict on ISA irq sharing now.
>>>    A bit too strict.
>>>
>>> /me goes dig out a old patch which never made it upstream for some
>>> reason I forgot.  Attached.
>>>        
>> This is wrong. Two devices should never be manipulating the same qemu_irq
>> object.  If you want multiple devices connected to the same IRQ then you need
>> an explicit multiplexer. e.g. arm_timer.c:sp804_set_irq.
>>      
> So... what we have to do here?
>
> I've looked at the mentioned routine, here it is:
>
> /* Merge the IRQs from the two component devices.  */
> static void sp804_set_irq(void *opaque, int irq, int level)
> {
>      sp804_state *s = (sp804_state *)opaque;
>
>      s->level[irq] = level;
>      qemu_set_irq(s->irq, s->level[0] || s->level[1]);
> }
>
> But I know nothing about qemu internals, so don't quite
> understand how to do this in case of serial ports.  I
> see it is tracking two timers and raises the irq level
> if at least one half is raised...  That to say - I've
> got the idea, but how to apply it to serial ports?
>    

Two devices have the same s->irq.  Give each on its own qemu_irq, and 
feed it into a multiplexer that ORs them together and sends the result 
to the interrupt controller's qemu_irq:


S1 ----qemu_irq---->+------+

                     |  mux  +---qemu_irq----->  irq controller

S2 ----qemu_irq---->+------+


(the ascii art will come out all wrong, I know it)

-- 

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

  reply	other threads:[~2010-03-22  9:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-17  8:38 >2 serial ports? Michael Tokarev
2010-03-17  9:17 ` Gerd Hoffmann
2010-03-17  9:17   ` [Qemu-devel] " Gerd Hoffmann
2010-03-17 10:33   ` Michael Tokarev
2010-03-17 10:33     ` [Qemu-devel] " Michael Tokarev
2010-03-17 11:18   ` Paul Brook
2010-03-17 11:18     ` Paul Brook
2010-03-22  8:35     ` Michael Tokarev
2010-03-22  8:35       ` Michael Tokarev
2010-03-22  9:02       ` Avi Kivity [this message]
2010-03-22  9:02         ` Avi Kivity
2010-03-17  9:19 ` Neo Jia
2010-03-17 10:35   ` Michael Tokarev
2010-03-17 18:45     ` Neo Jia
2010-03-17 19:16       ` Michael Tokarev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BA73226.6030704@redhat.com \
    --to=avi@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.