All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Cao jin <caoj.fnst@cn.fujitsu.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	qemu-devel@nongnu.org, izumi.taku@jp.fujitsu.com
Subject: Re: [PATCH] vfio pci: kernel support of error recovery only for non fatal error
Date: Mon, 20 Mar 2017 16:34:22 +0200	[thread overview]
Message-ID: <20170320163316-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170320083056.3f2a5603@t450s.home>

On Mon, Mar 20, 2017 at 08:30:56AM -0600, Alex Williamson wrote:
> > > What about the case where the user has not registered for receiving
> > > non-fatal errors, now we send an error signal on both error_detected
> > > and slot_reset.  Is that useful/desirable?
> > >   
> > 
> > Not desirable, but seems not harmful, guest user will stop anyway. How
> > to avoid this case gracefully seems not easy.
> 
> "Not harmful" is presuming the behavior of the user.  QEMU might not be
> the only consumer of these events.  Is it possible to receive a
> slot_reset without first receiving an error_detected?  If not then we
> can easily track our action for one to decide on the behavior for the
> other.  Thanks,
> 
> Alex

I would just pass maximum info to userspace and let it decide.

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Cao jin <caoj.fnst@cn.fujitsu.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	qemu-devel@nongnu.org, izumi.taku@jp.fujitsu.com
Subject: Re: [Qemu-devel] [PATCH] vfio pci: kernel support of error recovery only for non fatal error
Date: Mon, 20 Mar 2017 16:34:22 +0200	[thread overview]
Message-ID: <20170320163316-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20170320083056.3f2a5603@t450s.home>

On Mon, Mar 20, 2017 at 08:30:56AM -0600, Alex Williamson wrote:
> > > What about the case where the user has not registered for receiving
> > > non-fatal errors, now we send an error signal on both error_detected
> > > and slot_reset.  Is that useful/desirable?
> > >   
> > 
> > Not desirable, but seems not harmful, guest user will stop anyway. How
> > to avoid this case gracefully seems not easy.
> 
> "Not harmful" is presuming the behavior of the user.  QEMU might not be
> the only consumer of these events.  Is it possible to receive a
> slot_reset without first receiving an error_detected?  If not then we
> can easily track our action for one to decide on the behavior for the
> other.  Thanks,
> 
> Alex

I would just pass maximum info to userspace and let it decide.

-- 
MST

  reply	other threads:[~2017-03-20 15:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27  7:28 [PATCH] vfio pci: kernel support of error recovery only for non fatal error Cao jin
2017-02-27  7:28 ` [Qemu-devel] " Cao jin
2017-02-27  7:28 ` Cao jin
2017-02-27 16:16 ` Michael S. Tsirkin
2017-02-27 16:16   ` [Qemu-devel] " Michael S. Tsirkin
2017-02-28  1:31   ` Cao jin
2017-02-28  1:31     ` [Qemu-devel] " Cao jin
2017-02-28  1:31     ` Cao jin
2017-03-13 22:06 ` Alex Williamson
2017-03-13 22:06   ` [Qemu-devel] " Alex Williamson
2017-03-20 12:50   ` Cao jin
2017-03-20 12:50     ` [Qemu-devel] " Cao jin
2017-03-20 14:30     ` Alex Williamson
2017-03-20 14:30       ` [Qemu-devel] " Alex Williamson
2017-03-20 14:34       ` Michael S. Tsirkin [this message]
2017-03-20 14:34         ` Michael S. Tsirkin
2017-03-21  8:05       ` Cao jin
2017-03-21  8:05         ` [Qemu-devel] " Cao jin
2017-03-20 14:32     ` Michael S. Tsirkin
2017-03-20 14:32       ` [Qemu-devel] " Michael S. Tsirkin
2017-03-21  5:18       ` Alex Williamson
2017-03-21  5:18         ` [Qemu-devel] " Alex Williamson

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=20170320163316-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 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.