On Tue, Oct 27, 2020 at 01:54:26PM +0100, Igor Mammedov wrote: > 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?
PCIESlot maybe? > * what would be the request in this case, i.e. create PCI device anyways > and try to signal hotplug event later? that was my idea, yes. > * what would baremethal do in such case? exactly the same, human would wait until blinking stops. > * what to do in case guest is never ready, what user should do in such case? As in guest is stuck? Do we care? It can't use the device. > * can be such device be removed? why not? device_del could complete immediately ... > 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). I'd say let's get expected behaviour for existing commands first. We can add events and stuff on top. > > > > 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 > > > > > >
