Re: Vdagent not working on xen linux hvm DomUs

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 05/12/2013 17:02, Wei Liu ha scritto:
> On Thu, Dec 05, 2013 at 04:50:03PM +0100, Fabio Fantoni wrote:
>> Il 05/12/2013 16:21, Wei Liu ha scritto:
>>> On Thu, Dec 05, 2013 at 04:11:52PM +0100, Fabio Fantoni wrote:
>>> [...]
>>>> I saw a draft of virtio disk/net implementation for xen here:
>>>> http://wiki.xen.org/wiki/Virtio_On_Xen
>>>>
>>>> There are 2 kernel patch to support virtio on pv domUs:
>>>> http://downloads.xen.org/Wiki/VirtioOnXen/linux-01-virtio-xenbus.patch
>>>> http://downloads.xen.org/Wiki/VirtioOnXen/linux-02-virtio-ring.patch
>>>>
>>> Do not use these patches, they were experimental.
>>>
>>>> What about virtio on hvm linux? Maybe
>>>>  From wiki it seems virtio kernel patches only needed for pv domUs.
>>>> Could be these patches needed to have virtio fully working also for
>>>> hvm domUs?
>>>>
>>> Virtio for HVM guests should work out of the box. You probably need to
>>> prevent kernel from unplugging emulated devices.
>>>
>>> Wei.
>> Thanks for reply.
>>
>> I not mean virtio disk/net but virtio-serial channels used for
>> example by spice vdagent.
>> The libxl implentation xen side is correct and on windows domUs
>> vdagent is working (I'm using it since 2 year).
>> On linux domUs I found that virtio ports under /dev are missed/not
>> created and I not understand why.
> That's probably unplugged by Xen platform PCI device.
>
>> Recently I tried also with xen_platform_pci=0 and the Konrad's patch
>> (xen/pvhvm: If xen_platform_pci=0 is set don't blow up) but to no
>> avail.
>>
> I haven't followed up that patch so I am not sure what's happening.
>
> Wei.
>
>> Thanks for any reply.

I did another tests, adding pci=nomsi to kernel boot option creates 
virtio-serial ports correctly and vdagent works also on linux domUs, I 
also tried to enable the xen platform and also in that case vdagent works.
So the problem is only about msi.
Added xen-devel to cc.
Any ideas on how to fix permanently without adding pci=nomsi?

Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 11:15:17AM +0100, Fabio Fantoni wrote:
[...]
> >>
> >>I not mean virtio disk/net but virtio-serial channels used for
> >>example by spice vdagent.
> >>The libxl implentation xen side is correct and on windows domUs
> >>vdagent is working (I'm using it since 2 year).
> >>On linux domUs I found that virtio ports under /dev are missed/not
> >>created and I not understand why.
> >That's probably unplugged by Xen platform PCI device.
> >
> >>Recently I tried also with xen_platform_pci=0 and the Konrad's patch
> >>(xen/pvhvm: If xen_platform_pci=0 is set don't blow up) but to no
> >>avail.
> >>
> >I haven't followed up that patch so I am not sure what's happening.
> >
> >Wei.
> >
> >>Thanks for any reply.
> 
> I did another tests, adding pci=nomsi to kernel boot option creates
> virtio-serial ports correctly and vdagent works also on linux domUs,
> I also tried to enable the xen platform and also in that case
> vdagent works.
> So the problem is only about msi.
> Added xen-devel to cc.
> Any ideas on how to fix permanently without adding pci=nomsi?
> 

As I remember it I wrote a patch for QEMU to make it capable of
injecting MSI interrupt in Xen long time ago so it should work fine.

Wei.

> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 11:50, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 11:15:17AM +0100, Fabio Fantoni wrote:
> [...]
>>>> I not mean virtio disk/net but virtio-serial channels used for
>>>> example by spice vdagent.
>>>> The libxl implentation xen side is correct and on windows domUs
>>>> vdagent is working (I'm using it since 2 year).
>>>> On linux domUs I found that virtio ports under /dev are missed/not
>>>> created and I not understand why.
>>> That's probably unplugged by Xen platform PCI device.
>>>
>>>> Recently I tried also with xen_platform_pci=0 and the Konrad's patch
>>>> (xen/pvhvm: If xen_platform_pci=0 is set don't blow up) but to no
>>>> avail.
>>>>
>>> I haven't followed up that patch so I am not sure what's happening.
>>>
>>> Wei.
>>>
>>>> Thanks for any reply.
>> I did another tests, adding pci=nomsi to kernel boot option creates
>> virtio-serial ports correctly and vdagent works also on linux domUs,
>> I also tried to enable the xen platform and also in that case
>> vdagent works.
>> So the problem is only about msi.
>> Added xen-devel to cc.
>> Any ideas on how to fix permanently without adding pci=nomsi?
>>
> As I remember it I wrote a patch for QEMU to make it capable of
> injecting MSI interrupt in Xen long time ago so it should work fine.
>
> Wei.

Is this?
http://git.qemu.org/?p=qemu.git;a=commit;h=f1dbf015dfb0aa7f66f710a1f1bc58b662951de2

thenis there a xen and/or qemu regression?

>
>> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 12:15:30PM +0100, Fabio Fantoni wrote:
> Il 06/12/2013 11:50, Wei Liu ha scritto:
> >On Fri, Dec 06, 2013 at 11:15:17AM +0100, Fabio Fantoni wrote:
> >[...]
> >>>>I not mean virtio disk/net but virtio-serial channels used for
> >>>>example by spice vdagent.
> >>>>The libxl implentation xen side is correct and on windows domUs
> >>>>vdagent is working (I'm using it since 2 year).
> >>>>On linux domUs I found that virtio ports under /dev are missed/not
> >>>>created and I not understand why.
> >>>That's probably unplugged by Xen platform PCI device.
> >>>
> >>>>Recently I tried also with xen_platform_pci=0 and the Konrad's patch
> >>>>(xen/pvhvm: If xen_platform_pci=0 is set don't blow up) but to no
> >>>>avail.
> >>>>
> >>>I haven't followed up that patch so I am not sure what's happening.
> >>>
> >>>Wei.
> >>>
> >>>>Thanks for any reply.
> >>I did another tests, adding pci=nomsi to kernel boot option creates
> >>virtio-serial ports correctly and vdagent works also on linux domUs,
> >>I also tried to enable the xen platform and also in that case
> >>vdagent works.
> >>So the problem is only about msi.
> >>Added xen-devel to cc.
> >>Any ideas on how to fix permanently without adding pci=nomsi?
> >>
> >As I remember it I wrote a patch for QEMU to make it capable of
> >injecting MSI interrupt in Xen long time ago so it should work fine.
> >
> >Wei.
> 
> Is this?
> http://git.qemu.org/?p=qemu.git;a=commit;h=f1dbf015dfb0aa7f66f710a1f1bc58b662951de2
> 
> thenis there a xen and/or qemu regression?
> 

Yes that one.

Not sure if it is a regression, because nobody ever tried to use
virtio-serial in Xen AFAICT.

If you find virtio-net / virtio-blk not working, then there's a problem.

Wei.

> >
> >>Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 12:19, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 12:15:30PM +0100, Fabio Fantoni wrote:
>> Il 06/12/2013 11:50, Wei Liu ha scritto:
>>> On Fri, Dec 06, 2013 at 11:15:17AM +0100, Fabio Fantoni wrote:
>>> [...]
>>>>>> I not mean virtio disk/net but virtio-serial channels used for
>>>>>> example by spice vdagent.
>>>>>> The libxl implentation xen side is correct and on windows domUs
>>>>>> vdagent is working (I'm using it since 2 year).
>>>>>> On linux domUs I found that virtio ports under /dev are missed/not
>>>>>> created and I not understand why.
>>>>> That's probably unplugged by Xen platform PCI device.
>>>>>
>>>>>> Recently I tried also with xen_platform_pci=0 and the Konrad's patch
>>>>>> (xen/pvhvm: If xen_platform_pci=0 is set don't blow up) but to no
>>>>>> avail.
>>>>>>
>>>>> I haven't followed up that patch so I am not sure what's happening.
>>>>>
>>>>> Wei.
>>>>>
>>>>>> Thanks for any reply.
>>>> I did another tests, adding pci=nomsi to kernel boot option creates
>>>> virtio-serial ports correctly and vdagent works also on linux domUs,
>>>> I also tried to enable the xen platform and also in that case
>>>> vdagent works.
>>>> So the problem is only about msi.
>>>> Added xen-devel to cc.
>>>> Any ideas on how to fix permanently without adding pci=nomsi?
>>>>
>>> As I remember it I wrote a patch for QEMU to make it capable of
>>> injecting MSI interrupt in Xen long time ago so it should work fine.
>>>
>>> Wei.
>> Is this?
>> http://git.qemu.org/?p=qemu.git;a=commit;h=f1dbf015dfb0aa7f66f710a1f1bc58b662951de2
>>
>> thenis there a xen and/or qemu regression?
>>
> Yes that one.
>
> Not sure if it is a regression, because nobody ever tried to use
> virtio-serial in Xen AFAICT.
>
> If you find virtio-net / virtio-blk not working, then there's a problem.
>
> Wei.

Thanks for reply, where is the latest versions of your libxl patch for 
virtio-net / virtio-blk support?
I found only the old version of 2011 on wiki.
Is this the latest and I must updated it to be working on xen unstable 
before testing it?

Thanks for any reply.

>>>> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 12:28:00PM +0100, Fabio Fantoni wrote:
[...]
> 
> Thanks for reply, where is the latest versions of your libxl patch
> for virtio-net / virtio-blk support?
> I found only the old version of 2011 on wiki.
> Is this the latest and I must updated it to be working on xen
> unstable before testing it?
> 

That is not needed if you want to use virtio-net.

Just specify 'model=virtio-net-pci' in you nic spec then you're fine.

Wei.

> Thanks for any reply.
> 
> >>>>Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 12:31, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 12:28:00PM +0100, Fabio Fantoni wrote:
> [...]
>> Thanks for reply, where is the latest versions of your libxl patch
>> for virtio-net / virtio-blk support?
>> I found only the old version of 2011 on wiki.
>> Is this the latest and I must updated it to be working on xen
>> unstable before testing it?
>>
> That is not needed if you want to use virtio-net.
>
> Just specify 'model=virtio-net-pci' in you nic spec then you're fine.
>
> Wei.

I did a fast test with virtio nic, xen platform disabled 
(xen_platform_pci=0 plus konrad patch) and qemu crashed on ubuntu Saucy 
hvm domU start with this error on qemu log:
xen_ram_addr_from_mapcache, could not find 0x7f34c08afff8
I tried both with/without pci=nomsi, same result.
Then it seems that with virtio net there is a further problem.
Tell me if you need other tests/details and I'll post them.

Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 12:51:34PM +0100, Fabio Fantoni wrote:
> Il 06/12/2013 12:31, Wei Liu ha scritto:
> >On Fri, Dec 06, 2013 at 12:28:00PM +0100, Fabio Fantoni wrote:
> >[...]
> >>Thanks for reply, where is the latest versions of your libxl patch
> >>for virtio-net / virtio-blk support?
> >>I found only the old version of 2011 on wiki.
> >>Is this the latest and I must updated it to be working on xen
> >>unstable before testing it?
> >>
> >That is not needed if you want to use virtio-net.
> >
> >Just specify 'model=virtio-net-pci' in you nic spec then you're fine.
> >
> >Wei.
> 
> I did a fast test with virtio nic, xen platform disabled
> (xen_platform_pci=0 plus konrad patch) and qemu crashed on ubuntu
> Saucy hvm domU start with this error on qemu log:
> xen_ram_addr_from_mapcache, could not find 0x7f34c08afff8
> I tried both with/without pci=nomsi, same result.
> Then it seems that with virtio net there is a further problem.
> Tell me if you need other tests/details and I'll post them.

So the same config works with other emulated nic (say, the default
rtl8139 / e1000)?

> 
> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 12:57, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 12:51:34PM +0100, Fabio Fantoni wrote:
>> Il 06/12/2013 12:31, Wei Liu ha scritto:
>>> On Fri, Dec 06, 2013 at 12:28:00PM +0100, Fabio Fantoni wrote:
>>> [...]
>>>> Thanks for reply, where is the latest versions of your libxl patch
>>>> for virtio-net / virtio-blk support?
>>>> I found only the old version of 2011 on wiki.
>>>> Is this the latest and I must updated it to be working on xen
>>>> unstable before testing it?
>>>>
>>> That is not needed if you want to use virtio-net.
>>>
>>> Just specify 'model=virtio-net-pci' in you nic spec then you're fine.
>>>
>>> Wei.
>> I did a fast test with virtio nic, xen platform disabled
>> (xen_platform_pci=0 plus konrad patch) and qemu crashed on ubuntu
>> Saucy hvm domU start with this error on qemu log:
>> xen_ram_addr_from_mapcache, could not find 0x7f34c08afff8
>> I tried both with/without pci=nomsi, same result.
>> Then it seems that with virtio net there is a further problem.
>> Tell me if you need other tests/details and I'll post them.
> So the same config works with other emulated nic (say, the default
> rtl8139 / e1000)?
>
>> Thanks for any reply.

Yes, I retried all cases removing only virtio net and no qemu crash.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 01:49:51PM +0100, Fabio Fantoni wrote:
> Il 06/12/2013 12:57, Wei Liu ha scritto:
> >On Fri, Dec 06, 2013 at 12:51:34PM +0100, Fabio Fantoni wrote:
> >>Il 06/12/2013 12:31, Wei Liu ha scritto:
> >>>On Fri, Dec 06, 2013 at 12:28:00PM +0100, Fabio Fantoni wrote:
> >>>[...]
> >>>>Thanks for reply, where is the latest versions of your libxl patch
> >>>>for virtio-net / virtio-blk support?
> >>>>I found only the old version of 2011 on wiki.
> >>>>Is this the latest and I must updated it to be working on xen
> >>>>unstable before testing it?
> >>>>
> >>>That is not needed if you want to use virtio-net.
> >>>
> >>>Just specify 'model=virtio-net-pci' in you nic spec then you're fine.
> >>>
> >>>Wei.
> >>I did a fast test with virtio nic, xen platform disabled
> >>(xen_platform_pci=0 plus konrad patch) and qemu crashed on ubuntu
> >>Saucy hvm domU start with this error on qemu log:
> >>xen_ram_addr_from_mapcache, could not find 0x7f34c08afff8
> >>I tried both with/without pci=nomsi, same result.
> >>Then it seems that with virtio net there is a further problem.
> >>Tell me if you need other tests/details and I'll post them.
> >So the same config works with other emulated nic (say, the default
> >rtl8139 / e1000)?
> >
> >>Thanks for any reply.
> 
> Yes, I retried all cases removing only virtio net and no qemu crash.

And Konrad's patch did prevent kernel from unplugging the emulated
devices?

I used virtio-net-pci in EFI several days ago it worked fine, so it is
possible that there's a bug in kernel.

If there's really a regression I would not be too surprise because
nobody is actively using it so we're not actively testing this feature.

You can try xen_emul_unplug=never in *guest kernel command line* to see
if it changes anything.

Wei.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 13:55, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 01:49:51PM +0100, Fabio Fantoni wrote:
>> Il 06/12/2013 12:57, Wei Liu ha scritto:
>>> On Fri, Dec 06, 2013 at 12:51:34PM +0100, Fabio Fantoni wrote:
>>>> Il 06/12/2013 12:31, Wei Liu ha scritto:
>>>>> On Fri, Dec 06, 2013 at 12:28:00PM +0100, Fabio Fantoni wrote:
>>>>> [...]
>>>>>> Thanks for reply, where is the latest versions of your libxl patch
>>>>>> for virtio-net / virtio-blk support?
>>>>>> I found only the old version of 2011 on wiki.
>>>>>> Is this the latest and I must updated it to be working on xen
>>>>>> unstable before testing it?
>>>>>>
>>>>> That is not needed if you want to use virtio-net.
>>>>>
>>>>> Just specify 'model=virtio-net-pci' in you nic spec then you're fine.
>>>>>
>>>>> Wei.
>>>> I did a fast test with virtio nic, xen platform disabled
>>>> (xen_platform_pci=0 plus konrad patch) and qemu crashed on ubuntu
>>>> Saucy hvm domU start with this error on qemu log:
>>>> xen_ram_addr_from_mapcache, could not find 0x7f34c08afff8
>>>> I tried both with/without pci=nomsi, same result.
>>>> Then it seems that with virtio net there is a further problem.
>>>> Tell me if you need other tests/details and I'll post them.
>>> So the same config works with other emulated nic (say, the default
>>> rtl8139 / e1000)?
>>>
>>>> Thanks for any reply.
>> Yes, I retried all cases removing only virtio net and no qemu crash.
> And Konrad's patch did prevent kernel from unplugging the emulated
> devices?
>
> I used virtio-net-pci in EFI several days ago it worked fine, so it is
> possible that there's a bug in kernel.
>
> If there's really a regression I would not be too surprise because
> nobody is actively using it so we're not actively testing this feature.
>
> You can try xen_emul_unplug=never in *guest kernel command line* to see
> if it changes anything.
>
> Wei.

I tried 2 cases with xen_emul_unplug=never:
- with xen platform disabled (xen_platform_pci=0 plus konrad patch) and 
pci=nomsi
- with xen_platform_pci=1 and without pci kernel parameter
on both cases qemu crash with same error:
xen_ram_addr_from_mapcache, could not find 0x7fdecf624968

On your virtio net test you have added only 'model=virtio-net-pci' on 
vif line of domU's xl cfg or you did other changes?

Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
[...]
> 
> I tried 2 cases with xen_emul_unplug=never:
> - with xen platform disabled (xen_platform_pci=0 plus konrad patch)
> and pci=nomsi
> - with xen_platform_pci=1 and without pci kernel parameter
> on both cases qemu crash with same error:
> xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
> 
> On your virtio net test you have added only 'model=virtio-net-pci'
> on vif line of domU's xl cfg or you did other changes?
> 

No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.

You can probably try to generate core file and use gdb to get the
backtrace to see what QEMU is trying to access.

Wei.

> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 14:17, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
> [...]
>> I tried 2 cases with xen_emul_unplug=never:
>> - with xen platform disabled (xen_platform_pci=0 plus konrad patch)
>> and pci=nomsi
>> - with xen_platform_pci=1 and without pci kernel parameter
>> on both cases qemu crash with same error:
>> xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
>>
>> On your virtio net test you have added only 'model=virtio-net-pci'
>> on vif line of domU's xl cfg or you did other changes?
>>
> No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.

I'm using xen's upstream qemu (master of 
git://xenbits.xen.org/qemu-upstream-unstable.git)

>
> You can probably try to generate core file and use gdb to get the
> backtrace to see what QEMU is trying to access.

Is there an howto for it please?

>
> Wei.
>
>> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 02:51:50PM +0100, Fabio Fantoni wrote:
> Il 06/12/2013 14:17, Wei Liu ha scritto:
> >On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
> >[...]
> >>I tried 2 cases with xen_emul_unplug=never:
> >>- with xen platform disabled (xen_platform_pci=0 plus konrad patch)
> >>and pci=nomsi
> >>- with xen_platform_pci=1 and without pci kernel parameter
> >>on both cases qemu crash with same error:
> >>xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
> >>
> >>On your virtio net test you have added only 'model=virtio-net-pci'
> >>on vif line of domU's xl cfg or you did other changes?
> >>
> >No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.
> 
> I'm using xen's upstream qemu (master of
> git://xenbits.xen.org/qemu-upstream-unstable.git)
> 

Not only the branch is important but also the changeset.

I'm using the hash specified in Config.mk

> >
> >You can probably try to generate core file and use gdb to get the
> >backtrace to see what QEMU is trying to access.
> 
> Is there an howto for it please?
> 

There's lots of tutorial on how configure Linux to let a process be able
to generate core file, how to debug core file with GDB. It's not
QEMU-specific.

Wei.

> >
> >Wei.
> >
> >>Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 15:40, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 02:51:50PM +0100, Fabio Fantoni wrote:
>> Il 06/12/2013 14:17, Wei Liu ha scritto:
>>> On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
>>> [...]
>>>> I tried 2 cases with xen_emul_unplug=never:
>>>> - with xen platform disabled (xen_platform_pci=0 plus konrad patch)
>>>> and pci=nomsi
>>>> - with xen_platform_pci=1 and without pci kernel parameter
>>>> on both cases qemu crash with same error:
>>>> xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
>>>>
>>>> On your virtio net test you have added only 'model=virtio-net-pci'
>>>> on vif line of domU's xl cfg or you did other changes?
>>>>
>>> No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.
>> I'm using xen's upstream qemu (master of
>> git://xenbits.xen.org/qemu-upstream-unstable.git)
>>
> Not only the branch is important but also the changeset.
>
> I'm using the hash specified in Config.mk

qemu of my tests about virtio:
git log
commit b97307ecaad98360f41ea36cd9674ef810c4f8cf
Author: Matthew Daley <mattjd@gmail.com>
Date:   Thu Oct 10 14:10:48 2013 +0000

     xen_disk: mark ioreq as mapped before unmapping in error case

>
>>> You can probably try to generate core file and use gdb to get the
>>> backtrace to see what QEMU is trying to access.
>> Is there an howto for it please?
>>
> There's lots of tutorial on how configure Linux to let a process be able
> to generate core file, how to debug core file with GDB. It's not
> QEMU-specific.
>
> Wei.
>
>>> Wei.
>>>
>>>> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 03:49:30PM +0100, Fabio Fantoni wrote:
> Il 06/12/2013 15:40, Wei Liu ha scritto:
> >On Fri, Dec 06, 2013 at 02:51:50PM +0100, Fabio Fantoni wrote:
> >>Il 06/12/2013 14:17, Wei Liu ha scritto:
> >>>On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
> >>>[...]
> >>>>I tried 2 cases with xen_emul_unplug=never:
> >>>>- with xen platform disabled (xen_platform_pci=0 plus konrad patch)
> >>>>and pci=nomsi
> >>>>- with xen_platform_pci=1 and without pci kernel parameter
> >>>>on both cases qemu crash with same error:
> >>>>xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
> >>>>
> >>>>On your virtio net test you have added only 'model=virtio-net-pci'
> >>>>on vif line of domU's xl cfg or you did other changes?
> >>>>
> >>>No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.
> >>I'm using xen's upstream qemu (master of
> >>git://xenbits.xen.org/qemu-upstream-unstable.git)
> >>
> >Not only the branch is important but also the changeset.
> >
> >I'm using the hash specified in Config.mk
> 
> qemu of my tests about virtio:
> git log
> commit b97307ecaad98360f41ea36cd9674ef810c4f8cf
> Author: Matthew Daley <mattjd@gmail.com>
> Date:   Thu Oct 10 14:10:48 2013 +0000
> 
>     xen_disk: mark ioreq as mapped before unmapping in error case
> 

There's lots of changesets between this one and the one I use so doing
bisection is the only way to find out where the regression was
introduced.

Wei.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 15:55, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 03:49:30PM +0100, Fabio Fantoni wrote:
>> Il 06/12/2013 15:40, Wei Liu ha scritto:
>>> On Fri, Dec 06, 2013 at 02:51:50PM +0100, Fabio Fantoni wrote:
>>>> Il 06/12/2013 14:17, Wei Liu ha scritto:
>>>>> On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
>>>>> [...]
>>>>>> I tried 2 cases with xen_emul_unplug=never:
>>>>>> - with xen platform disabled (xen_platform_pci=0 plus konrad patch)
>>>>>> and pci=nomsi
>>>>>> - with xen_platform_pci=1 and without pci kernel parameter
>>>>>> on both cases qemu crash with same error:
>>>>>> xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
>>>>>>
>>>>>> On your virtio net test you have added only 'model=virtio-net-pci'
>>>>>> on vif line of domU's xl cfg or you did other changes?
>>>>>>
>>>>> No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.
>>>> I'm using xen's upstream qemu (master of
>>>> git://xenbits.xen.org/qemu-upstream-unstable.git)
>>>>
>>> Not only the branch is important but also the changeset.
>>>
>>> I'm using the hash specified in Config.mk
>> qemu of my tests about virtio:
>> git log
>> commit b97307ecaad98360f41ea36cd9674ef810c4f8cf
>> Author: Matthew Daley <mattjd@gmail.com>
>> Date:   Thu Oct 10 14:10:48 2013 +0000
>>
>>      xen_disk: mark ioreq as mapped before unmapping in error case
>>
> There's lots of changesets between this one and the one I use so doing
> bisection is the only way to find out where the regression was
> introduced.
>
> Wei.

So your are still using qemu 1.3?

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 04:25:48PM +0100, Fabio Fantoni wrote:
[...]
> So your are still using qemu 1.3?

Yes, my tree for that particular task was quite old. In that case you
need to bisect across 3 versions, not an easy job.

Wei.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 06, 2013 at 02:55:46PM +0000, Wei Liu wrote:
> On Fri, Dec 06, 2013 at 03:49:30PM +0100, Fabio Fantoni wrote:
> > Il 06/12/2013 15:40, Wei Liu ha scritto:
> > >On Fri, Dec 06, 2013 at 02:51:50PM +0100, Fabio Fantoni wrote:
> > >>Il 06/12/2013 14:17, Wei Liu ha scritto:
> > >>>On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
> > >>>[...]
> > >>>>I tried 2 cases with xen_emul_unplug=never:
> > >>>>- with xen platform disabled (xen_platform_pci=0 plus konrad patch)
> > >>>>and pci=nomsi
> > >>>>- with xen_platform_pci=1 and without pci kernel parameter
> > >>>>on both cases qemu crash with same error:
> > >>>>xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
> > >>>>
> > >>>>On your virtio net test you have added only 'model=virtio-net-pci'
> > >>>>on vif line of domU's xl cfg or you did other changes?
> > >>>>
> > >>>No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.
> > >>I'm using xen's upstream qemu (master of
> > >>git://xenbits.xen.org/qemu-upstream-unstable.git)
> > >>
> > >Not only the branch is important but also the changeset.
> > >
> > >I'm using the hash specified in Config.mk
> > 
> > qemu of my tests about virtio:
> > git log
> > commit b97307ecaad98360f41ea36cd9674ef810c4f8cf
> > Author: Matthew Daley <mattjd@gmail.com>
> > Date:   Thu Oct 10 14:10:48 2013 +0000
> > 
> >     xen_disk: mark ioreq as mapped before unmapping in error case
> > 
> 
> There's lots of changesets between this one and the one I use so doing
> bisection is the only way to find out where the regression was
> introduced.
> 

And, if you're really going to look into this I suggest you start with
virtio related changesets, then Xen mapcache changesets (I suspect
there's many changes to this code, but anyway it is worth looking at).

Good luck.

Wei.

> Wei.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 06/12/2013 16:39, Wei Liu ha scritto:
> On Fri, Dec 06, 2013 at 02:55:46PM +0000, Wei Liu wrote:
>> On Fri, Dec 06, 2013 at 03:49:30PM +0100, Fabio Fantoni wrote:
>>> Il 06/12/2013 15:40, Wei Liu ha scritto:
>>>> On Fri, Dec 06, 2013 at 02:51:50PM +0100, Fabio Fantoni wrote:
>>>>> Il 06/12/2013 14:17, Wei Liu ha scritto:
>>>>>> On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
>>>>>> [...]
>>>>>>> I tried 2 cases with xen_emul_unplug=never:
>>>>>>> - with xen platform disabled (xen_platform_pci=0 plus konrad patch)
>>>>>>> and pci=nomsi
>>>>>>> - with xen_platform_pci=1 and without pci kernel parameter
>>>>>>> on both cases qemu crash with same error:
>>>>>>> xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
>>>>>>>
>>>>>>> On your virtio net test you have added only 'model=virtio-net-pci'
>>>>>>> on vif line of domU's xl cfg or you did other changes?
>>>>>>>
>>>>>> No, nothing more. But I'm using Xen's QEMU upstream, not vanilla QEMU.
>>>>> I'm using xen's upstream qemu (master of
>>>>> git://xenbits.xen.org/qemu-upstream-unstable.git)
>>>>>
>>>> Not only the branch is important but also the changeset.
>>>>
>>>> I'm using the hash specified in Config.mk
>>> qemu of my tests about virtio:
>>> git log
>>> commit b97307ecaad98360f41ea36cd9674ef810c4f8cf
>>> Author: Matthew Daley <mattjd@gmail.com>
>>> Date:   Thu Oct 10 14:10:48 2013 +0000
>>>
>>>      xen_disk: mark ioreq as mapped before unmapping in error case
>>>
>> There's lots of changesets between this one and the one I use so doing
>> bisection is the only way to find out where the regression was
>> introduced.
>>
> And, if you're really going to look into this I suggest you start with
> virtio related changesets, then Xen mapcache changesets (I suspect
> there's many changes to this code, but anyway it is worth looking at).
>
> Good luck.
>
> Wei.

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

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 10/12/2013 15:38, Fabio Fantoni ha scritto:
> Il 06/12/2013 16:39, Wei Liu ha scritto:
>> On Fri, Dec 06, 2013 at 02:55:46PM +0000, Wei Liu wrote:
>>> On Fri, Dec 06, 2013 at 03:49:30PM +0100, Fabio Fantoni wrote:
>>>> Il 06/12/2013 15:40, Wei Liu ha scritto:
>>>>> On Fri, Dec 06, 2013 at 02:51:50PM +0100, Fabio Fantoni wrote:
>>>>>> Il 06/12/2013 14:17, Wei Liu ha scritto:
>>>>>>> On Fri, Dec 06, 2013 at 02:10:24PM +0100, Fabio Fantoni wrote:
>>>>>>> [...]
>>>>>>>> I tried 2 cases with xen_emul_unplug=never:
>>>>>>>> - with xen platform disabled (xen_platform_pci=0 plus konrad 
>>>>>>>> patch)
>>>>>>>> and pci=nomsi
>>>>>>>> - with xen_platform_pci=1 and without pci kernel parameter
>>>>>>>> on both cases qemu crash with same error:
>>>>>>>> xen_ram_addr_from_mapcache, could not find 0x7fdecf624968
>>>>>>>>
>>>>>>>> On your virtio net test you have added only 'model=virtio-net-pci'
>>>>>>>> on vif line of domU's xl cfg or you did other changes?
>>>>>>>>
>>>>>>> No, nothing more. But I'm using Xen's QEMU upstream, not vanilla 
>>>>>>> QEMU.
>>>>>> I'm using xen's upstream qemu (master of
>>>>>> git://xenbits.xen.org/qemu-upstream-unstable.git)
>>>>>>
>>>>> Not only the branch is important but also the changeset.
>>>>>
>>>>> I'm using the hash specified in Config.mk
>>>> qemu of my tests about virtio:
>>>> git log
>>>> commit b97307ecaad98360f41ea36cd9674ef810c4f8cf
>>>> Author: Matthew Daley <mattjd@gmail.com>
>>>> Date:   Thu Oct 10 14:10:48 2013 +0000
>>>>
>>>>      xen_disk: mark ioreq as mapped before unmapping in error case
>>>>
>>> There's lots of changesets between this one and the one I use so doing
>>> bisection is the only way to find out where the regression was
>>> introduced.
>>>
>> And, if you're really going to look into this I suggest you start with
>> virtio related changesets, then Xen mapcache changesets (I suspect
>> there's many changes to this code, but anyway it is worth looking at).
>>
>> Good luck.
>>
>> Wei.
>
> 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 tested with Ubuntu Saucy and Ubuntu Precise, both with latest 
xen-unstable (based on commit 2f718161bc292bfbdf1aeefd3932b73c0965373d), 
latest commit of qemu-upstream-4.3-testing.git and latest stable seabios 
from debian package 1.7.3-2
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.

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

Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

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

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

> Thanks for any reply.

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

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

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.

> 
> >
> >>Thanks for any reply.

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

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

[Wei Liu]

On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
[...]
> 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.
> 

I did a quick test with Xen's QEMU, currently at

commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
Merge: 79c097d 35bdc13
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date:   Tue Jun 25 11:34:24 2013 +0000

    Merge remote branch 'perard/cpu-hotplug-port-v2' into xen-staging-master-7

from git://xenbits.xen.org/qemu-upstream-unstable.git

My guest is Squeeze with stock kernel 2.6.32.

vif=['model=virtio-net-pci,bridge=xenbr0']

No pci=nomsi in guest kernel command line.

Everything worked fine. And /proc/interrupts shows that it's indeed
using MSI for virtio PCI.

I'm kind of confused. (And in the long run of this thread I probably
didn't remember everything.)

Wei.

> Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 12/12/2013 16:23, Wei Liu ha scritto:
> On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
> [...]
>> 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.
>>

> I did a quick test with Xen's QEMU, currently at
>
> commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
> Merge: 79c097d 35bdc13
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date:   Tue Jun 25 11:34:24 2013 +0000
>
>      Merge remote branch 'perard/cpu-hotplug-port-v2' into xen-staging-master-7
>
> from git://xenbits.xen.org/qemu-upstream-unstable.git
>
> My guest is Squeeze with stock kernel 2.6.32.
>
> vif=['model=virtio-net-pci,bridge=xenbr0']
>
> No pci=nomsi in guest kernel command line.
>
> Everything worked fine. And /proc/interrupts shows that it's indeed
> using MSI for virtio PCI.
>
> I'm kind of confused. (And in the long run of this thread I probably
> didn't remember everything.)
>
> Wei.

I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6 (xen_disk: 
mark ioreq as mapped before unmapping in error case)" from 
git://xenbits.xen.org/qemu-upstream-4.3-testing.git.
There are only 4 commits difference between mine and your test.
FWIK the only other difference is domUs kernel versions, and the msi 
problem is probably a regression between kernel 2.6.32 and 3.2 (the 
"older" domUs used in my tests was Precise with kernel 3.2).
Tomorrow I'll try also with squeeze.

RIguardo invece l'altra regressione qemu tra il 4 e 22 luglio che da 
errore xen mapcache usando virtio net puoi aiutarmi?
Another question: the qemu 1.6 regression between july 4th-22nd commits 
(qemu crash on domU kernel load with xen mapcache error with virtio 
net), could you help me?

Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 12/12/2013 17:05, Fabio Fantoni ha scritto:
> Il 12/12/2013 16:23, Wei Liu ha scritto:
>> On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
>> [...]
>>> 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.
>>>
>
>> I did a quick test with Xen's QEMU, currently at
>>
>> commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
>> Merge: 79c097d 35bdc13
>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Date:   Tue Jun 25 11:34:24 2013 +0000
>>
>>      Merge remote branch 'perard/cpu-hotplug-port-v2' into 
>> xen-staging-master-7
>>
>> from git://xenbits.xen.org/qemu-upstream-unstable.git
>>
>> My guest is Squeeze with stock kernel 2.6.32.
>>
>> vif=['model=virtio-net-pci,bridge=xenbr0']
>>
>> No pci=nomsi in guest kernel command line.
>>
>> Everything worked fine. And /proc/interrupts shows that it's indeed
>> using MSI for virtio PCI.
>>
>> I'm kind of confused. (And in the long run of this thread I probably
>> didn't remember everything.)
>>
>> Wei.
>
> I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6 
> (xen_disk: mark ioreq as mapped before unmapping in error case)" from 
> git://xenbits.xen.org/qemu-upstream-4.3-testing.git.
> There are only 4 commits difference between mine and your test.
> FWIK the only other difference is domUs kernel versions, and the msi 
> problem is probably a regression between kernel 2.6.32 and 3.2 (the 
> "older" domUs used in my tests was Precise with kernel 3.2).
> Tomorrow I'll try also with squeeze.

I tested with squeeze and with qemu 1.3.1, virtio net works also without 
pci=nomsi, so seems kernel regression about msi using xen (that make 
virtio devices not working) between versions 2.6.32 and 3.2.
Any idea about solve it?

>
> RIguardo invece l'altra regressione qemu tra il 4 e 22 luglio che da 
> errore xen mapcache usando virtio net puoi aiutarmi?
> Another question: the qemu 1.6 regression between july 4th-22nd 
> commits (qemu crash on domU kernel load with xen mapcache error with 
> virtio net), could you help me?
>
> Thanks for any reply.

I did another test about this qemu regression and I'm unable to decrease 
the range of commits :(

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Fri, Dec 13, 2013 at 10:51:01AM +0100, Fabio Fantoni wrote:
> Il 12/12/2013 17:05, Fabio Fantoni ha scritto:
> >Il 12/12/2013 16:23, Wei Liu ha scritto:
> >>On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
> >>[...]
> >>>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.
> >>>
> >
> >>I did a quick test with Xen's QEMU, currently at
> >>
> >>commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
> >>Merge: 79c097d 35bdc13
> >>Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>Date:   Tue Jun 25 11:34:24 2013 +0000
> >>
> >>     Merge remote branch 'perard/cpu-hotplug-port-v2' into
> >>xen-staging-master-7
> >>
> >>from git://xenbits.xen.org/qemu-upstream-unstable.git
> >>
> >>My guest is Squeeze with stock kernel 2.6.32.
> >>
> >>vif=['model=virtio-net-pci,bridge=xenbr0']
> >>
> >>No pci=nomsi in guest kernel command line.
> >>
> >>Everything worked fine. And /proc/interrupts shows that it's indeed
> >>using MSI for virtio PCI.
> >>
> >>I'm kind of confused. (And in the long run of this thread I probably
> >>didn't remember everything.)
> >>
> >>Wei.
> >
> >I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6
> >(xen_disk: mark ioreq as mapped before unmapping in error case)"
> >from git://xenbits.xen.org/qemu-upstream-4.3-testing.git.
> >There are only 4 commits difference between mine and your test.
> >FWIK the only other difference is domUs kernel versions, and the
> >msi problem is probably a regression between kernel 2.6.32 and 3.2
> >(the "older" domUs used in my tests was Precise with kernel 3.2).
> >Tomorrow I'll try also with squeeze.
> 
> I tested with squeeze and with qemu 1.3.1, virtio net works also
> without pci=nomsi, so seems kernel regression about msi using xen
> (that make virtio devices not working) between versions 2.6.32 and
> 3.2.
> Any idea about solve it?
> 

3.2 is still old to be honest. I don't think we have the bandwidth to
look at it.

It's never easy to debug problem involving several software components.
The right thing to do is to use a) latest stable kernel tree which is
still actively maintained, b) Linus's tree. Only those actively trees
maintained / developed people have incentive / time to look at.

If you're using a specific distro kernel, it would be probably helpful
to report bug to that distro as well -- only if you're sure the bug
you're seeing is distro kernel's bug.

If you really want this feature so bad. I would sugguest you try latest
stable kernel to see if it works. If not, you probably need to revisit
your requirement and look for another route to achieve your goal.

Wei.

Re: Vdagent not working on xen linux hvm DomUs

[Fabio Fantoni]

Il 13/12/2013 17:22, Wei Liu ha scritto:
> On Fri, Dec 13, 2013 at 10:51:01AM +0100, Fabio Fantoni wrote:
>> Il 12/12/2013 17:05, Fabio Fantoni ha scritto:
>>> Il 12/12/2013 16:23, Wei Liu ha scritto:
>>>> On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
>>>> [...]
>>>>> 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.
>>>>>
>>>> I did a quick test with Xen's QEMU, currently at
>>>>
>>>> commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
>>>> Merge: 79c097d 35bdc13
>>>> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> Date:   Tue Jun 25 11:34:24 2013 +0000
>>>>
>>>>      Merge remote branch 'perard/cpu-hotplug-port-v2' into
>>>> xen-staging-master-7
>>>>
>>> >from git://xenbits.xen.org/qemu-upstream-unstable.git
>>>> My guest is Squeeze with stock kernel 2.6.32.
>>>>
>>>> vif=['model=virtio-net-pci,bridge=xenbr0']
>>>>
>>>> No pci=nomsi in guest kernel command line.
>>>>
>>>> Everything worked fine. And /proc/interrupts shows that it's indeed
>>>> using MSI for virtio PCI.
>>>>
>>>> I'm kind of confused. (And in the long run of this thread I probably
>>>> didn't remember everything.)
>>>>
>>>> Wei.
>>> I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6
>>> (xen_disk: mark ioreq as mapped before unmapping in error case)"
>> >from git://xenbits.xen.org/qemu-upstream-4.3-testing.git.
>>> There are only 4 commits difference between mine and your test.
>>> FWIK the only other difference is domUs kernel versions, and the
>>> msi problem is probably a regression between kernel 2.6.32 and 3.2
>>> (the "older" domUs used in my tests was Precise with kernel 3.2).
>>> Tomorrow I'll try also with squeeze.
>> I tested with squeeze and with qemu 1.3.1, virtio net works also
>> without pci=nomsi, so seems kernel regression about msi using xen
>> (that make virtio devices not working) between versions 2.6.32 and
>> 3.2.
>> Any idea about solve it?
>>
> 3.2 is still old to be honest. I don't think we have the bandwidth to
> look at it.
>
> It's never easy to debug problem involving several software components.
> The right thing to do is to use a) latest stable kernel tree which is
> still actively maintained, b) Linus's tree. Only those actively trees
> maintained / developed people have incentive / time to look at.
>
> If you're using a specific distro kernel, it would be probably helpful
> to report bug to that distro as well -- only if you're sure the bug
> you're seeing is distro kernel's bug.
>
> If you really want this feature so bad. I would sugguest you try latest
> stable kernel to see if it works. If not, you probably need to revisit
> your requirement and look for another route to achieve your goal.
>
> Wei.

Thanks for your reply.
About kernel msi regression I'll do other tests.
Could it be useful to try this patch:
https://bugzilla.kernel.org/attachment.cgi?id=113791
or is it totally unrelated?



About the other regression (the upstream qemu 1.6 regression that causes 
qemu crash with virtio net) can someone help me please?

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

Thanks for any reply.

Re: Vdagent not working on xen linux hvm DomUs

[Wei Liu]

On Tue, Dec 17, 2013 at 05:01:58PM +0100, Fabio Fantoni wrote:
[...]
> 
> Thanks for your reply.
> About kernel msi regression I'll do other tests.
> Could it be useful to try this patch:
> https://bugzilla.kernel.org/attachment.cgi?id=113791
> or is it totally unrelated?
> 

Not sure. You would probably need to check if the kernel version you
used already has that patch.

IIRC, you said e1000 worked without pci=nomsi. And, if I remember
correctly, e1000 uses MSI by default. So it is hard to tell what is
broken. After all so many different components, so many different
versions of different components are involved.

Wei.

Re: Vdagent not working on xen linux hvm DomUs

[Michael S. Tsirkin]

On Tue, Dec 17, 2013 at 05:01:58PM +0100, Fabio Fantoni wrote:
> Il 13/12/2013 17:22, Wei Liu ha scritto:
> >On Fri, Dec 13, 2013 at 10:51:01AM +0100, Fabio Fantoni wrote:
> >>Il 12/12/2013 17:05, Fabio Fantoni ha scritto:
> >>>Il 12/12/2013 16:23, Wei Liu ha scritto:
> >>>>On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
> >>>>[...]
> >>>>>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

bisect is pretty aggressive sometimes but there are only 300
commits in this range.
So you should be able to just try them all automatically.

It might be a good idea to start a new thread,
Cc all lists at the same time and collect the
information known so far.

Also, is MSI working for Xen generally?
Maybe it's not a virtio-only problem.

> >>>>>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.
> >>>>>
> >>>>I did a quick test with Xen's QEMU, currently at
> >>>>
> >>>>commit 1c514a7734b7f98625a0d18d5e8ee7581f26e50c
> >>>>Merge: 79c097d 35bdc13
> >>>>Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >>>>Date:   Tue Jun 25 11:34:24 2013 +0000
> >>>>
> >>>>     Merge remote branch 'perard/cpu-hotplug-port-v2' into
> >>>>xen-staging-master-7
> >>>>
> >>>>from git://xenbits.xen.org/qemu-upstream-unstable.git
> >>>>My guest is Squeeze with stock kernel 2.6.32.
> >>>>
> >>>>vif=['model=virtio-net-pci,bridge=xenbr0']
> >>>>
> >>>>No pci=nomsi in guest kernel command line.
> >>>>
> >>>>Everything worked fine. And /proc/interrupts shows that it's indeed
> >>>>using MSI for virtio PCI.
> >>>>
> >>>>I'm kind of confused. (And in the long run of this thread I probably
> >>>>didn't remember everything.)
> >>>>
> >>>>Wei.
> >>>I tried with "commit e16435c95be86244bd92c5c26579bd4298aa65a6
> >>>(xen_disk: mark ioreq as mapped before unmapping in error case)"
> >>>from git://xenbits.xen.org/qemu-upstream-4.3-testing.git.
> >>>There are only 4 commits difference between mine and your test.
> >>>FWIK the only other difference is domUs kernel versions, and the
> >>>msi problem is probably a regression between kernel 2.6.32 and 3.2
> >>>(the "older" domUs used in my tests was Precise with kernel 3.2).
> >>>Tomorrow I'll try also with squeeze.
> >>I tested with squeeze and with qemu 1.3.1, virtio net works also
> >>without pci=nomsi, so seems kernel regression about msi using xen
> >>(that make virtio devices not working) between versions 2.6.32 and
> >>3.2.
> >>Any idea about solve it?
> >>
> >3.2 is still old to be honest. I don't think we have the bandwidth to
> >look at it.
> >
> >It's never easy to debug problem involving several software components.
> >The right thing to do is to use a) latest stable kernel tree which is
> >still actively maintained, b) Linus's tree. Only those actively trees
> >maintained / developed people have incentive / time to look at.
> >
> >If you're using a specific distro kernel, it would be probably helpful
> >to report bug to that distro as well -- only if you're sure the bug
> >you're seeing is distro kernel's bug.
> >
> >If you really want this feature so bad. I would sugguest you try latest
> >stable kernel to see if it works. If not, you probably need to revisit
> >your requirement and look for another route to achieve your goal.
> >
> >Wei.
> 
> Thanks for your reply.
> About kernel msi regression I'll do other tests.
> Could it be useful to try this patch:
> https://bugzilla.kernel.org/attachment.cgi?id=113791
> or is it totally unrelated?
> 
> 
> 
> About the other regression (the upstream qemu 1.6 regression that
> causes qemu crash with virtio net) can someone help me please?

It might be a good idea to start a separate thread
related to this, too.


> >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?
> 
> Thanks for any reply.

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

[Wei Liu]

On Mon, Mar 10, 2014 at 02:32:31PM +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 17, 2013 at 05:01:58PM +0100, Fabio Fantoni wrote:
> > Il 13/12/2013 17:22, Wei Liu ha scritto:
> > >On Fri, Dec 13, 2013 at 10:51:01AM +0100, Fabio Fantoni wrote:
> > >>Il 12/12/2013 17:05, Fabio Fantoni ha scritto:
> > >>>Il 12/12/2013 16:23, Wei Liu ha scritto:
> > >>>>On Thu, Dec 12, 2013 at 02:10:23PM +0100, Fabio Fantoni wrote:
> > >>>>[...]
> > >>>>>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
> 
> bisect is pretty aggressive sometimes but there are only 300
> commits in this range.
> So you should be able to just try them all automatically.
> 
> It might be a good idea to start a new thread,
> Cc all lists at the same time and collect the
> information known so far.
> 
> Also, is MSI working for Xen generally?
> Maybe it's not a virtio-only problem.
> 

I beleive MSI works to some degree. There's code to inject MSI interrupt
to HVM guest in QEMU.

Wei.