qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Fam Zheng <famz@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset
Date: Thu, 12 Mar 2015 11:57:32 +0100	[thread overview]
Message-ID: <20150312115534-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <CAFEAcA-fU_FtbLAWt70s2cG3N9T-nsHsuZhNiep1Zd-uGix5_A@mail.gmail.com>

On Thu, Mar 12, 2015 at 10:21:47AM +0000, Peter Maydell wrote:
> On 12 March 2015 at 10:16, Michael S. Tsirkin <mst@redhat.com> wrote:
> > So thinking about this more, by the time kdump tries to reset device,
> > linux has probably already disabled the IRQ at the APIC level.
> > Isn't that the case? If so, the patch won't help, will it?
> 
> Trying to deassert (or worse, assert) interrupt lines in
> device reset functions is slightly bogus, yes. In general
> the theory is that the interrupt controller the interrupt line
> is connected to should have its own reset handling which
> treats the line as going back to deasserted, because there's
> no guarantee made about which of the two ends of the line
> gets its reset handler called first.
> 
> Things are not really this neat in practice though. (There's
> no good way to model a device which comes out of reset with
> a line asserted, for instance.)
> 
> -- PMM

This isn't a device reset though.
The function that Fam is touching is called
when a special "virtio reset" register to
poked by the driver.
It only resets part of the device, not all of it,
and it seems reasonable to ask that it clear the
interrupt.

So I think the patch is correct, even if just for
spec compliance reasons, but I would like to
find out and document the workloads that actually
benefit.

-- 
MST

  reply	other threads:[~2015-03-12 10:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12  6:40 [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset Fam Zheng
2015-03-12  7:22 ` Michael S. Tsirkin
2015-03-12  7:58   ` Fam Zheng
2015-03-12  9:41 ` Michael S. Tsirkin
2015-03-12 10:00   ` Fam Zheng
2015-03-12 10:06     ` Michael S. Tsirkin
2015-03-12 10:16     ` Michael S. Tsirkin
2015-03-12 10:21       ` Peter Maydell
2015-03-12 10:57         ` Michael S. Tsirkin [this message]
2015-03-12 11:04           ` Peter Maydell
2015-03-12 11:15             ` Michael S. Tsirkin
2015-03-13  6:07               ` Fam Zheng
2015-03-13  6:28                 ` Fam Zheng
2015-03-16  5:09                   ` Michael S. Tsirkin
2015-03-13 14:19                 ` Michael S. Tsirkin

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=20150312115534-mutt-send-email-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=famz@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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).