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

Re: [Xen-devel] [PATCH RFC 1 6/8] xen/pt: Make xen_pt_unregister_device idempotent



On Thu, 2 Jul 2015, Konrad Rzeszutek Wilk wrote:
> > > @@ -858,15 +863,20 @@ static void xen_pt_unregister_device(PCIDevice *d)
> > >                             machine_irq, errno);
> > >              }
> > >          }
> > > +        s->machine_irq = 0;
> > >      }
> > >  
> > >      /* delete all emulated config registers */
> > >      xen_pt_config_delete(s);
> > >  
> > > -    memory_listener_unregister(&s->memory_listener);
> > > -    memory_listener_unregister(&s->io_listener);
> > > -
> > > -    xen_host_pci_device_put(&s->real_device);
> > > +    if (s->listener_set) {
> > > +        memory_listener_unregister(&s->memory_listener);
> > > +        memory_listener_unregister(&s->io_listener);
> > > +        s->listener_set = false;
> > 
> > If you call QTAILQ_INIT on memory_listener and io_listener, then you
> > simply check on QTAILQ_EMPTY and remove listener_set.
> 
> No dice. For that to work they need to be QTAIL_HEAD while
> they are of QTAILQ_ENTRY.
> 
> That is, the include/exec/memory.h:
> struct MemoryListener {
>  ...
>       AddressSpace *address_space_filter;
>       QTAILQ_ENTRY(MemoryListener) link;
> }
> 
> And the QTAILQ_EMPTY checks for '>tqh_first' while the
> QTAILQ_ENTRY only defines two pointers: tqe_next and tqe_prev.

Ah, that is true.  In that case maybe it is OK to introduce
listener_set, rather than messing up with QTAILQ definitions or having
checks like memory_listener->link->tqe_next ==
memory_listener->link->tqe_prev.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.