From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jason Wang <jasowang@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>,
Felipe Franciosi <felipe@nutanix.com>
Subject: Re: [PATCH] virtio: skip guest index check on device load
Date: Wed, 28 Oct 2020 07:30:55 -0400 [thread overview]
Message-ID: <20201028072812-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20201028110038.GE221115@stefanha-x1.localdomain>
On Wed, Oct 28, 2020 at 11:00:38AM +0000, Stefan Hajnoczi wrote:
> On Tue, Oct 27, 2020 at 09:04:46AM -0400, Michael S. Tsirkin wrote:
> > It's not a waste of time, it's just a lot of work
> > within guests.
>
> Luckily it does no harm to set the NEEDS_RESET bit even if the guest
> doesn't handle it.
>
> If the guest driver is unaware it may continue to submit requests to the
> device for a while. The device emulation code stops accepting new
> requests though. This means the device will become unresponsive until
> reset, which is not ideal but okay in the case where the device was put
> into an invalid state.
There is no actual rule that device must stop processing requests.
Driver can only assume that is the case after it started the
actual reset.
> I agree that supporting NEEDS_RESET transparently inside guests is
> difficult. The driver needs to reset and resume the device without
> reporting errors to applications. In some cases drivers may not have
> enough state in order to do that. It's also tricky to test all code
> paths. I guess this is why no one has done it: drivers shouldn't enter
> the NEEDS_RESET state anyway and handling it is complex.
>
> Stefan
next prev parent reply other threads:[~2020-10-28 11:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 15:13 [PATCH] virtio: skip guest index check on device load Felipe Franciosi
2020-10-27 11:30 ` Stefan Hajnoczi
2020-10-27 12:25 ` Michael S. Tsirkin
2020-10-27 12:53 ` Felipe Franciosi
2020-10-27 12:56 ` Michael S. Tsirkin
2020-10-27 13:02 ` Felipe Franciosi
2020-10-27 13:04 ` Michael S. Tsirkin
2020-10-28 11:00 ` Stefan Hajnoczi
2020-10-28 11:30 ` Michael S. Tsirkin [this message]
2020-10-28 12:44 ` Stefan Hajnoczi
2020-11-02 13:31 ` Dr. David Alan Gilbert
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=20201028072812-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=armbru@redhat.com \
--cc=felipe@nutanix.com \
--cc=jasowang@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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.