qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] pci: Refuse to hotplug PCI Devices when the Guest OS is not


From: David Gibson
Subject: Re: [PATCH] pci: Refuse to hotplug PCI Devices when the Guest OS is not ready
Date: Wed, 28 Oct 2020 14:34:34 +1100

On Tue, 27 Oct 2020 09:02:06 -0400
"Michael S. Tsirkin" <mst@redhat.com> 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 <dgibson@redhat.com>
Principal Software Engineer, Virtualization, Red Hat

Attachment: pgpA07kYNpKPy.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]