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

[Fabio Fantoni]

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.

>
>> 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.



>
>> Thanks for any reply.