Re: Problem Reading from XenStore in DomU

[Dagaen Golomb <dgolomb@seas.upenn.edu>]

>>>>> 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.
>
> I could try this. Right now I did the same procedure, but not the same
> .config (both times working off of oldconfig and then defaults for new
> items). I'm not sure if it really makes sense for them to have the
> same config, but its worth a try.
>
> Also, I did use the same source for both.

I just tried using the same .config file/ Due to differences in the
tool stack (notably gcc version) the only change was the stack
protector from strong to normal. Compiled as expected but issue still
persists. I'm stumped.

Regards,
Dagaen Golomb
Ph.D. Student, University of Pennsylvania

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