[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PULL 22/27] hw/xen: Add emulated implementation of XenStore operations
On Tue, 7 Mar 2023 at 18:27, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > From: David Woodhouse <dwmw@xxxxxxxxxxxx> > > Now that we have an internal implementation of XenStore, we can populate > the xenstore_backend_ops to allow PV backends to talk to it. > > Watches can't be processed with immediate callbacks because that would > call back into XenBus code recursively. Defer them to a QEMUBH to be run > as appropriate from the main loop. We use a QEMUBH per XS handle, and it > walks all the watches (there shouldn't be many per handle) to fire any > which have pending events. We *could* have done it differently but this > allows us to use the same struct watch_event as we have for the guest > side, and keeps things relatively simple. > +static struct qemu_xs_handle *xs_be_open(void) > +{ > + XenXenstoreState *s = xen_xenstore_singleton; > + struct qemu_xs_handle *h; > + > + if (!s && !s->impl) { Coverity points out that this will dereference a NULL pointer if you hand it one, and will happily let through a XenXenstoreState where s->impl is NULL. Should be "!s || !s->impl" I guess ? CID 1508131. > + errno = -ENOSYS; > + return NULL; > + } > + > + h = g_new0(struct qemu_xs_handle, 1); > + h->impl = s->impl; > + > + h->watch_bh = aio_bh_new(qemu_get_aio_context(), be_watch_bh, h); > + > + return h; > +} thanks -- PMM
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |