On Tue, 27 Oct 2020 09:02:06 -0400 "Michael S. Tsirkin" wrote: > On Tue, Oct 27, 2020 at 01:54:26PM +0100, Igor Mammedov wrote: > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > [...] > > 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. Actually, I don't think that will quite work. A whole chunk of the problem here is that because the device is realized, the guest sees it as part of its general scan *before* the hotplug event (ABP and PDC interrupts) appears. That makes the guest misinterpret the ABP as an *unplug* request. So delaying the interrupt without delaying the realize (or at least filtering config space access to it based on.. something) will just trigger the same problem AFAICT. > > * 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 ... > > [...] > > I'd say let's get expected behaviour for existing commands first. > We can add events and stuff on top. > > [...] > [...] > [...] > -- David Gibson Principal Software Engineer, Virtualization, Red Hat