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

Re: [Xen-devel] [win-pv-devel] XenBus_AddWatch

> -----Original Message-----
> From: win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel-
> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of hanji unit
> Sent: 31 December 2014 15:15
> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx; xen-devel@xxxxxxxxxxxxx
> Subject: [win-pv-devel] XenBus_AddWatch
> Hello, I am calling XenBus_AddWatch API from a DomU guest in the
> win-pvdrivers xenpci driver, and noticed that I am not able to watch
> xenstore entries that are outside of the DomU's xenstore tree. For
> example, the following call in
> XenPci_EvtDeviceD0EntryPostInterruptsEnabled fails with response="EIO"
> even if the xenstore permissions for Container and Container/DomU in
> xenstore are both "b0":
> response = XenBus_AddWatch(xpdd, XN_BASE_GLOBAL,
> "Container/DomU",
> MyCallback, xpdd);
> However, the following call works and it watches a xenstore entry
> relative to DomUs xenstore tree:
> response = XenBus_AddWatch(xpdd, XBT_NIL, "DomU", MyCallback, xpdd);
> Writing to an entry outside the DomUs tree is allowed if permissions are b0:
> result = XnWriteString(xpdd, XN_BASE_GLOBAL, "Container/DomU", buffer);
> It seems like DomUs should be allowed to watch xenstore entries
> outside their trees. Is this a bug or is it by design?


  The API you're referring to is part of James Harper's GPLPV drivers I 
believe, which I'm no expert on. I would imagine the API simply passes error 
codes back from xenstored though so you should probably check 
xenstored-access.log, although EIO does sound like an odd code to get back.


> Thanks.
> _______________________________________________
> win-pv-devel mailing list
> win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel

Xen-devel mailing list



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