[Spice-devel] Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 11/12/2013 17:55, Wei Liu ha scritto:
> On Wed, Dec 11, 2013 at 05:11:37PM +0100, Fabio Fantoni wrote:
>> Il 11/12/2013 16:38, Wei Liu ha scritto:
>>> On Wed, Dec 11, 2013 at 02:41:57PM +0100, Fabio Fantoni wrote:
>>> [...]
>>>>> Thanks for your reply.
>>>>> Before starting bisection I tried with qemu 1.3.1 from
>>>>> qemu-upstream-4.3-testing.git
>>>>> No more crash with virtio net but it needs pci=nomsi to be
>>>>> working, same thing for vdagent, so seems that msi problem is with
>>>>> all virtio devices.
>>>>> Then the problems seem 2 different, on your build you have virtio
>>>>> devices working without setting pci=nomsi need to know the
>>>>> differences and find the cause.
>>>> Your test with virtio net working without pci=nomsi was on ovmf only
>>>> or you tried also with seabios?
>>> I only tried OVMF recently and since you were replying to this thread I
>>> presumed you used OVMF as well.
>> I not tried ovmf for this case, I'll do.
>> Based on your post seem that msi problem with virtio is missed on ovmf.
>>
> Not sure, it doesn't necessary mean that it uses MSI.
>
> Second thought on this, even if OVMF (the firmware) works it doesn't
> have anything to do with kernel.
>
> So the only option would be to fix the bug, not work around it.
>
>>>> I tested with Ubuntu Saucy and Ubuntu Precise, both with latest
>>>> xen-unstable (based on commit
>>>> 2f718161bc292bfbdf1aeefd3932b73c0965373d), latest commit of
>>> If you're using OVMF I suggest you update your branch to he latest
>>> master.
>>>
>>>> qemu-upstream-4.3-testing.git and latest stable seabios from debian
>>>> package 1.7.3-2
>>> So that you're not using seabios tree from xenbits?
>> debian package use upstream 1.7.3.2 version, so I not think do difference.
>>
>>>> On both case pci=nomsi was needed to have virtio net working.
>>>>
>>>> I watch the pdf of virtio spec. of this post:
>>>> http://lists.xen.org/archives/html/xen-devel/2013-12/msg01654.html
>>>> however, are not able to understand the possible cause of the
>>>> problem encountered with msi on virtio devices with xen.
>>>>
>>> That's not very relevant. The bug is in implementation.
>>>
>>>>> About the crash of qemu 1.6.1 with virtio net is confirmed that is
>>>>> a regression, is not critical because is not implement on libxl
>>>>> now but I'll do further research.
>>>>>
>>>>>
>>>> I test with qemu 1.4 and 1.5 and they haven't the regression showing
>>>> xenmap cache error with virtio net.
>>> So you've found out the bug was introduced in 1.6, good.
>>>
>>>> Watching history seems there aren't commits about xen mapcache
>>>> between 1.5 and 1.6, other xen and virtio changes are many, from a
>>>> quick look I could not find commit suspects to be tested.
>>>> Someone can suggest me the commits more suspects to be testedplease?
>>>>
>>> How many commits between 1.5 and 1.6? If it is not too many I think
>>> doing bisection would be a good idea.
>>>
>>> Wei.
>> I did other tests but take very long time due to a some of other
>> bugs fixes later.
>>
>> the results for now are:
>>
>> regression present on commit
>> c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013 15:14:18
>> (Merge remote-tracking branch 'bonzini/iommu-for-anthony') plus
>> cherry-pick of commit 755ec4ca0f92188458ad7ca549a75161cbdcf6ff pc:
>> Initializing ram_memory under Xen.
>>
>> qemu crash on hvm domU start for other problem of which I have not
>> found the fix for now:
>> commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013
>> 15:42:46 +0000 (ne2000: pass device to ne2000_setup_io, use it as
>> owner)
>> plus cherry-pick of commit 755ec4ca0f92188458ad7ca549a75161cbdcf6ff
>> pc: Initializing ram_memory under Xen.
>>
>> xl dmesg:
>> (d1) Multiprocessor initialisation:
>> (d1)  - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
>> (d1)  - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [2/8] ... done.
>> (d1) Testing HVM environment:
>> (d1)  - REP INSB across page boundaries ... Bad value at 0x00500000:
>> saw 98765400 ex
>> (d1) pected 987654ff
>> (d1) Bad value at 0x00500ffc: saw 00000000 expected ff000000
>> (d1) Bad value at 0x005ffffc: saw 00000000 expected ff000000
>> (d1) Bad value at 0x00601000: saw 00000000 expected 000000ff
>> (d1) failed
>> (d1)  - GS base MSRs and SWAPGS ... passed
>> (d1) Passed 1 of 2 tests
>> (d1) FAILED 1 of 2 tests
>> (d1) *** HVMLoader bug at tests.c:242
>> (d1) *** HVMLoader crashed.
>>
>>
> It crashes in HVMloader, not QEMU. So this is probably not what you
> need.
>
> Wei.

I did some other tests, I narrowed down the commit range to the one between:

commit c9fea5d701f8fd33f0843728ec264d95cee3ed37 Mon, 22 Jul 2013 
15:14:18 (Merge remote-tracking branch 'bonzini/iommu-for-anthony') 
where there is virtio net regression with xen

and

commit    962b03fcf509db25c847aa67c4eff574c240dcfe Thu, 4 Jul 2013 
15:42:43 +0000 (xen: Mark fixed platform I/O as unaligned)
where virtio net is working

I also tested:
commit 2562becfc126ed7678c662ee23b7c1fe135d8966 Mon, 15 Jul 2013 
19:02:41 +0000
and
commit dcb117bfda5af6f6ceb7231778d36d8bce4aee93 Thu, 4 Jul 2013 15:42:46 
+0000
but qemu crashes on xl create for another error and I haven't found 
which is the commit to apply with git cherry-pick so that I can check if 
the virtio net regression is present.

Can someone help me please?

I added also qemu-devel to cc.

Thanks for any reply.