On Tue, 27 Oct 2020 07:26:44 -0400 "Michael S. Tsirkin" <m...@redhat.com> wrote:
> On Mon, Oct 26, 2020 at 05:45:37PM +1100, David Gibson wrote: > > On Fri, 23 Oct 2020 09:26:48 +0300 > > Marcel Apfelbaum <marcel.apfelb...@gmail.com> wrote: > > > > > Hi Michael, > > > > > > On Thu, Oct 22, 2020 at 6:01 PM Michael S. Tsirkin <m...@redhat.com> > > > wrote: > > > > > > [...] [...] > > > Simplistic does not mean wrong or incorrect. > > > I fail to see why it is not enough. > > > > > > What QEMU can do better? Wait an unbounded time for the blinking to > > > finish? > > > > It certainly shouldn't wait an unbounded time. But a wait with timeout > > seems worth investigating to me. racy, timeout is bound to break once it's in overcommited env. > If it's helpful, I'd add a query to check state > so management can figure out why doesn't guest see device yet. that means mgmt would have to poll it and forward it to user somehow. > But otherwise just buffer the request until such time as > we can deliver it to guest ... I have more questions wrt the suggestion/workflow: * at what place would you suggest buffering it? * what would be the request in this case, i.e. create PCI device anyways and try to signal hotplug event later? * what would baremethal do in such case? * what to do in case guest is never ready, what user should do in such case? * can be such device be removed? not sure that all of this is worth of the effort and added complexity. alternatively: maybe ports can send QMP events about it's state changes, which end user would be able to see + error like in this patch. On top of it, mgmt could build a better UIx, like retry/notify logic if that's what user really wishes for and configures (it would be up to user to define behaviour). > > > What if we have a buggy guest with a kernel stuck in blinking? > > > Is QEMU's responsibility to emulate the operator itself? Because the > > > operator > > > is the one who is supposed to wait. > > > > > > > > > Thanks, > > > Marcel > > > > > > [...] > > > > > > -- > > David Gibson <dgib...@redhat.com> > > Principal Software Engineer, Virtualization, Red Hat > > >
