From: David Gibson <dgibson@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Julia Suvorova <jusual@redhat.com>,
qemu devel list <qemu-devel@nongnu.org>
Subject: Re: [PATCH] pci: Refuse to hotplug PCI Devices when the Guest OS is not ready
Date: Fri, 23 Oct 2020 14:49:01 +1100 [thread overview]
Message-ID: <20201023144901.5bd908a1@yekko.fritz.box> (raw)
In-Reply-To: <20201022110016-mutt-send-email-mst@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1607 bytes --]
On Thu, 22 Oct 2020 11:01:04 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Oct 22, 2020 at 05:50:51PM +0300, Marcel Apfelbaum wrote:
> [...]
>
> Right. After detecting just failing unconditionally it a bit too
> simplistic IMHO.
There's also another factor here, which I thought I'd mentioned
already, but looks like I didn't: I think we're still missing some
details in what's going on.
The premise for this patch is that plugging while the indicator is in
transition state is allowed to fail in any way on the guest side. I
don't think that's a reasonable interpretation, because it's unworkable
for physical hotplug. If the indicator starts blinking while you're in
the middle of shoving a card in, you'd be in trouble.
So, what I'm assuming here is that while "don't plug while blinking" is
the instruction for the operator to obey as best they can, on the guest
side the rule has to be "start blinking, wait a while and by the time
you leave blinking state again, you can be confident any plugs or
unplugs have completed". Obviously still racy in the strict computer
science sense, but about the best you can do with slow humans in the
mix.
So, qemu should of course endeavour to follow that rule as though it
was a human operator on a physical machine and not plug when the
indicator is blinking. *But* the qemu plug will in practice be fast
enough that if we're hitting real problems here, it suggests the guest
is still doing something wrong.
--
David Gibson <dgibson@redhat.com>
Principal Software Engineer, Virtualization, Red Hat
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-10-23 3:50 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 11:40 [PATCH] pci: Refuse to hotplug PCI Devices when the Guest OS is not ready Marcel Apfelbaum
2020-10-22 12:06 ` Michael S. Tsirkin
2020-10-22 12:56 ` David Gibson
2020-10-22 13:15 ` Michael S. Tsirkin
2020-10-23 3:30 ` David Gibson
2020-10-22 13:55 ` Marcel Apfelbaum
2020-10-22 14:01 ` Michael S. Tsirkin
2020-10-22 14:10 ` Marcel Apfelbaum
2020-10-22 14:32 ` Michael S. Tsirkin
2020-10-22 14:50 ` Marcel Apfelbaum
2020-10-22 15:01 ` Michael S. Tsirkin
2020-10-23 3:49 ` David Gibson [this message]
2020-10-23 6:47 ` Marcel Apfelbaum
2020-10-23 15:54 ` Michael S. Tsirkin
2020-10-23 17:27 ` Igor Mammedov
2020-10-26 6:38 ` David Gibson
2020-10-26 9:17 ` Peter Krempa
2020-10-26 6:35 ` David Gibson
2020-10-23 6:26 ` Marcel Apfelbaum
2020-10-26 6:45 ` David Gibson
2020-10-27 11:26 ` Michael S. Tsirkin
2020-10-27 12:54 ` Igor Mammedov
2020-10-27 13:02 ` Michael S. Tsirkin
2020-10-28 3:34 ` David Gibson
2020-10-28 3:31 ` David Gibson
2020-10-28 15:39 ` Igor Mammedov
2020-10-28 17:49 ` Michael S. Tsirkin
2020-10-27 11:30 ` Michael S. Tsirkin
2020-10-23 3:31 ` David Gibson
2020-11-11 12:35 ` Michael S. Tsirkin
2020-11-15 16:48 ` Marcel Apfelbaum
2020-11-11 16:09 ` Roman Kagan
2020-11-15 16:43 ` Marcel Apfelbaum
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=20201023144901.5bd908a1@yekko.fritz.box \
--to=dgibson@redhat.com \
--cc=jusual@redhat.com \
--cc=mst@redhat.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).