Re: Problem Reading from XenStore in DomU

[Meng Xu <xumengpanda@gmail.com>]

On Sun, May 15, 2016 at 3:54 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.
>>>
>>> The guest I mentioned before with the default kernel can still read
>>> and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
>>> running our kernel.
>>>
>>> The issue I'm having is with another newly created guest (i.e., it is
>>> not a copy of the working one, this is because I needed more space and
>>> couldn't expand the original disk image). It is also running Ubuntu
>>> 12.04 but has been upgraded to our modified kernel. On this guest I
>>> can write to the XenStore, and see that the writes were indeed
>>> successful using xenstore-ls in dom0. However, when this same guest
>>> attempts to read from the XenStore, it doesn't return an error code
>>> but instead just blocks indefinitely. I've waiting many minutes to
>>> make sure its not just blocking for a while, it appears like it will
>>> block forever. The block is happening when I start the transaction.
>>> I've also tried not using a transaction, in which case it blocks on
>>> the read itself.
>>>
>>> I have an inkling this may be something as simple as a configuration
>>> issue, but I can't seem to find anything. Also, the fact that writes
>>> work fine but reads do not is perplexing me.
>>>
>>> Any help would be appreciated!
>>
>> Nothing should block like this.  Without seeing your patch, I can't
>> comment as to whether you have accidentally broken things.
>
> I don't see any way the patch could be causing this. It simply adds
> another function and case clause to an already-existing hypercall, and
> when you call the hypercall with that option it returns the current
> budget of a passed-in vcpu. It doesn't even come close to touching
> grant mechanics, and doesn't modify any state - it simply returns a
> value that previously was hidden in the kernel.
>
>> Other avenues of investigation are to look at what the xenstored process
>> is doing in dom0 (is it idle? or is it spinning?), and to look in the
>> xenstored log file to see if anything suspicious occurs.
>
> I tried booting into older, stock kernels. They all work with the
> read. However, I do not see why the kernel modification would be the
> issue as described above. I also have the dom0 running this kernel and
> it reads and writes the XenStore just dandy. Are there any kernel
> config issues that could do this?

What if you use the .config of the kernel in the working domU to
compile the kernel in the not-working domU?
I assume you used the same kernel source code for both domUs.


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