From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: "Michael S. Tsirkin" <mst@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>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] virtio: skip guest index check on device load
Date: Mon, 2 Nov 2020 13:31:35 +0000 [thread overview]
Message-ID: <20201102133135.GA4845@work-vm> (raw)
In-Reply-To: <20201028110038.GE221115@stefanha-x1.localdomain>
* Stefan Hajnoczi (stefanha@redhat.com) 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.
>
> 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.
Is that required? I mean, what are the semantics of NEEDS_RESET - is
it assuming that you must be able to do a silent recovery?
Dave
> 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
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
prev parent reply other threads:[~2020-11-02 13: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
2020-10-28 12:44 ` Stefan Hajnoczi
2020-11-02 13:31 ` Dr. David Alan Gilbert [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=20201102133135.GA4845@work-vm \
--to=dgilbert@redhat.com \
--cc=armbru@redhat.com \
--cc=felipe@nutanix.com \
--cc=jasowang@redhat.com \
--cc=mst@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.