qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Duo jia <jiaduo19920301@gmail.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: How does qemu detect the completion of interrupt execution?
Date: Mon, 6 Sep 2021 10:24:55 +0100	[thread overview]
Message-ID: <CAFEAcA8_yfknWwRgz_kfYXQLHEk1bKgy0AHWQSX49OzodGNiyg@mail.gmail.com> (raw)
In-Reply-To: <CALUzjTZKYx92qkxxmcVTMJ5_b0_eL+kwjW5ZYsr8SDXi58EPpw@mail.gmail.com>

On Mon, 6 Sept 2021 at 03:47, Duo jia <jiaduo19920301@gmail.com> wrote:
>
> Thank you for your explanation.
>
>>  And finishing the execution of the interrupt routine will automatically
>> allow a pending second interrupt to be taken immediately
>
>
> I think this is a hardware feature. But how to achieve it with qemu

That is what my explanation was trying to tell you how to do.

In a bit more detail:
 * your interrupt controller device should assert the irq line
   to the CPU for as long as there is any pending interrupt
   (regardless of its priority). It should deassert it when
   there is no longer a pending interrupt (ie when the guest
   writes to the interrupt status register to clear the pending
   status of an interrupt, if that was the only pending interrupt
   then the interrupt controller should stop asserting the
   irq line).
 * your stm8_cpu_set_irq function should set and clear the
   CPU_INTERRUPT_HARD flag in interrupt_request so that it
   follows the irq line value
 * your .cpu_exec_interrupt function should only take the
   interrupt if the CCR.I1/I0 bits permit it. Otherwise it
   should return false (telling the QEMU core code that there
   was no interrupt taken). cpu_exec_interrupt should *not*
   clear the CPU_INTERRUPT_HARD flag, whether it decides to
   take an interrupt or not.
 * your do_interrupt function should set CCR.I1/I0 from the
   ITC_SPRx registers (as well as doing everything else that
   interrupt entry needs to do)
 * your implementation of iret should reload the CCR.I1/I0
   bits, the way the spec describes

There are other ways to structure this (mostly involving
tying the interrupt controller model and the CPU model
together more closely), but the above is the "classic"
and probably simplest way of doing it.

-- PMM


      reply	other threads:[~2021-09-06  9:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-06  4:29 How does qemu detect the completion of interrupt execution? Duo jia
2021-08-06 10:15 ` Peter Maydell
2021-08-10  7:04   ` Duo jia
2021-09-02  2:17   ` Duo jia
2021-09-02  7:43     ` Peter Maydell
2021-09-03  8:32       ` Duo jia
2021-09-03 10:25         ` Peter Maydell
     [not found]           ` <CALUzjTaDo94110xX7bAr4B5y_XEXqoFH==88hsgffau0rNgZAw@mail.gmail.com>
2021-09-03 11:19             ` Peter Maydell
2021-09-06  2:46               ` Duo jia
2021-09-06  9:24                 ` Peter Maydell [this message]

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=CAFEAcA8_yfknWwRgz_kfYXQLHEk1bKgy0AHWQSX49OzodGNiyg@mail.gmail.com \
    --to=peter.maydell@linaro.org \
    --cc=jiaduo19920301@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).