Re: Problem Reading from XenStore in DomU

[Meng Xu <xumengpanda@gmail.com>]

Hi Doug,

Do you happen to know if Xen has an existing mechanism to make
/dev/xen/xenbus as a default device for xenstored?

On Sun, May 15, 2016 at 11:30 PM, Dagaen Golomb <dgolomb@seas.upenn.edu> wrote:
>> >>>>> Hi All,
>> >>>>>
>> >>>>> I'm having an interesting issue. I am working on a project that
>> >>>>> requires me to share memory between dom0 and domUs. I have this
>> >>>>> successfully working using the grant table and the XenStore to
>> >>>>> communicate grefs.
>> >>>>>
>> >>>>> My issue is this. I have one domU running Ubuntu 12.04 with a
>> >>>>> default
>> >>>>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>> >>>>> My work also requires some kernel modifications, and we have made
>> >>>>> these changes in the 4.1.0 kernel. In particular, we've only added a
>> >>>>> simple hypercall. This modified kernel is what dom0 is running, on
>> >>>>> top
>> >>>>> of Xen 4.7 rc1.
>> >>>>
>> >>>> Without reading the rest of the thread but seeing the kernel
>> >>>> versions.
>> >>>> Can you check how you're communicating to xenstore? Is it via
>> >>>> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give
>> >>>> you
>> >>>> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer
>> >>>> should
>> >>>> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>> >>>> that default didn't land until Xen 4.7. Since you're on the right
>> >>>> versions I expect you're using /dev/xen/xenbus but you never know.
>> >>>
>> >>> How do I know which is being used? /dev/xen/xenbus is there and so is
>> >>> process/xen/xenbus. Could this be a problem with header version
>> >>> mismatches or something similar? I'm using the xen/xenstore.h header
>> >>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>> >>> should be in /dev/, and the old kernel is before 3.14 but the new one
>> >>> is after, but I would presume the standard headers are updated to
>> >>> account for this. Is there an easy way to check for this? Also, would
>> >>> the same issue cause writes to fails? Because writes from the same
>> >>> domain work fine, and appear to other domains using xenstore-ls.
>> >>>
>> >>> Regards,
>> >>> Dagaen Golomb
>> >>>
>> >>
>> >> Use strace on the process and see what gets opened.
>> >
>> > Ah, of course. It seems both the working and non-working domains are
>> > using /proc/...
>>
>> Then according to Doug, "Anything after 3.14 will give you
>> > deadlocks if you try to use /proc/xen/xenbus.". Maybe the non-working
>> > domU uses kernel version after 3.14.
>
> It does, being the custom kernel on version 4.1.0. But Dom0 uses this same
> exact kernel and reads/writes just fine! The only solution if this is indeed
> the problem appears to be changing the kernel source we build on or some
> hacky method such as symlinking /proc/.. to /dev/.., there has to be an
> elegant real solution to this...

Hi Dagaen,

Maybe we can try to create a symlink /proc/xen/xenbus to
/dev/xen/xenbus and see if works.

I'm not that sure about if you can just define a env. variable
XENSTORED_PATH to /dev/xen/xenbus to make /dev/xen/xenbus as a default
choice.. But it's no harm to try.

BTW, this is a useful link to refer to:
http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01679.html


Best Regards,

Meng
-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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