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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.mkqemu 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.
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.
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?
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.
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.
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.
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.
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 ofIf 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-2So 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.
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.
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.
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.
Wei Liu
2013-Dec-12 15:23 UTC
Re: [Spice-devel] Vdagent not working on xen linux hvm DomUs
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.
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.
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 :(
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.