Hi All,
This is a report based on our testing for Xen 4.4-unstable on Intel platforms.
Test environment:
Xen: Xen 4.4-unstable with qemu-upstream-unstable.git
Changeset: 27314:e6ca87e13937
Dom0: Linux kernel 3.10.5
Hardware: Intel Sandy Bridge, Ivy Bridge, Haswell systems
New bugs (3):
1. Large file remote copy in Windows guest (no GPL PV driver) cause networking
broken
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1862
2. device pass-through works even if VT-d is disabled in BIOS
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1866
3. "xl list" shows no guest vcpu status when setting maxcpus=1 in
hypervisor grub line
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1867
Fixed bugs (7):
1. [ACPI] Dom0 can''t resume from S3 sleep
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1707
2. ''xl vcpu-set'' can''t decrease the vCPU number of a
HVM guest
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1822
3. Live migration fail when migrating the same guest for more than 2 times
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1845
4. dom0 call trace when running sriov hvm guest with igbvf
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1852
5. Guest could''t find bootable device with memory more than 3600M
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1857
6.changing vCPU number of a HVM for several times will cause the guest panic
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1860
7. dom0 will panic when pcibacking a vt-d device on IVT-EP
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1868
Closed bug (1):
1. Sometimes Xen panic on ia32pae Sandybridge when restore guest
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1747
-- no need to track this.
Old bugs (11):
1. [XL]"xl vcpu-set" causes dom0 crash or panic
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1730
2. Dom0 cannot be shutdown before PCI device detachment from guest
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1826
3. Guest hang after resume from S3
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1828
4. xl pci-list shows one PCI device (PF or VF) could be assigned to two
different guests
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1834
5. [upstream qemu] Guest free memory with upstream qemu is 14MB lower than that
with qemu-xen-unstable.git
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1836
6. [upstream qemu]''maxvcpus=NUM'' item is not supported in
upstream QEMU
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1837
7. [upstream qemu] Guest console hangs after save/restore or live-migration when
setting ''hpet=0'' in guest config file
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1838
8. [upstream qemu] ''xen_platform_pci=0'' setting cannot make
the guest use emulated PCI devices by default
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1839
9. sometimes failed to online cpu in Dom0
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1851
10. Booting multiple guests will lead Dom0 call trace
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1853
11. After live migration, guest console continuously prints "Clocksource
tsc unstable"
http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1854
Best Regards,
Yongjie (Jay)
>>> On 08.08.13 at 09:13, "Ren, Yongjie" <yongjie.ren@intel.com> wrote: > Hi All, > This is a report based on our testing for Xen 4.4-unstable on Intel > platforms. > Test environment: > Xen: Xen 4.4-unstable with qemu-upstream-unstable.git > Changeset: 27314:e6ca87e13937 > Dom0: Linux kernel 3.10.5 > Hardware: Intel Sandy Bridge, Ivy Bridge, Haswell systems > > New bugs (3): > 1. Large file remote copy in Windows guest (no GPL PV driver) cause > networking broken > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1862 > 2. device pass-through works even if VT-d is disabled in BIOS > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1866Are you sure this was seen with 27314:e6ca87e13937? I ask because 27204:06c2f6031aff is supposed to be taking care of this (and it did in my and - I think - also in others'' testing). To make things even less clear, the bug itself mentions 27203 and 27214...> 3. "xl list" shows no guest vcpu status when setting maxcpus=1 in hypervisor > grub line > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1867What would you expect to see? If the guest is runnable, none of the flags would be set (not running, not blocked, not paused, not shut down, no shutdown reason, not dying). There simply is no "runnable" indicator, and on an overcommitted system with more than 1 pCPU you ought to be able to observe the same. Jan
> >>> On 08.08.13 at 09:13, "Ren, Yongjie" <yongjie.ren@intel.com> wrote: > > Hi All, > > This is a report based on our testing for Xen 4.4-unstable on Intel > > platforms. > > Test environment: > > Xen: Xen 4.4-unstable with qemu-upstream-unstable.git > > Changeset: 27314:e6ca87e13937 > > Dom0: Linux kernel 3.10.5 > > Hardware: Intel Sandy Bridge, Ivy Bridge, Haswell systems > > > > New bugs (3): > > 1. Large file remote copy in Windows guest (no GPL PV driver) cause > > networking broken > > > > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1862 > > 2. device pass-through works even if VT-d is disabled in BIOS > > > > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1866 > > Are you sure this was seen with 27314:e6ca87e13937? I ask because > 27204:06c2f6031aff is supposed to be taking care of this (and it did in my and - I > think - also in others'' testing). To make things even less clear, the bug itself > mentions 27203 and 27214... >Yes, it also exists in c/s 27204:06c2f6031aff, 27324:e9c802e5acc9. vt-d function had been disabled in BIOS, with "iommu=0" in grub line, "xl pci-assignable-add", "xl pci-attach" still works, and could passthrough to hvm guest, but the attached PCI device could not get IP.> > 3. "xl list" shows no guest vcpu status when setting maxcpus=1 in > > hypervisor grub line > > > > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1867 > > What would you expect to see? If the guest is runnable, none of the flags would > be set (not running, not blocked, not paused, not shut down, no shutdown > reason, not dying). There simply is no "runnable" indicator, and on an > overcommitted system with more than 1 pCPU you ought to be able to observe > the same. >Check it with c/s 27324:e9c802e5acc9 with up mode, the guest vcpus will show in "xentop" output after 20s and vcpu status changes too slow. The system may be overmmited to response, I will close the bug.> Songtao
>>> On 12.08.13 at 05:43, "Liu, SongtaoX" <songtaox.liu@intel.com> wrote: >> >>> On 08.08.13 at 09:13, "Ren, Yongjie" <yongjie.ren@intel.com> wrote: >> > 2. device pass-through works even if VT-d is disabled in BIOS >> > >> > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1866 >> >> Are you sure this was seen with 27314:e6ca87e13937? I ask because >> 27204:06c2f6031aff is supposed to be taking care of this (and it did in my > and - I >> think - also in others'' testing). To make things even less clear, the bug > itself >> mentions 27203 and 27214... >> > Yes, it also exists in c/s 27204:06c2f6031aff, 27324:e9c802e5acc9. > vt-d function had been disabled in BIOS, with "iommu=0" in grub line, > "xl pci-assignable-add", "xl pci-attach" still works, and could passthrough to > hvm guest, > but the attached PCI device could not get IP.Please provide proof of that (logs + xl output) - I don''t really trust this given the already mentioned confusion about changesets in the bug vs the report here. Jan
> -----Original Message----- > From: Jan Beulich [mailto:JBeulich@suse.com] > Sent: Monday, August 12, 2013 3:09 PM > To: Liu, SongtaoX; Ren, Yongjie > Cc: Zhou, Chao; Xu, Jiajun; Xu, YongweiX; Tian, Yongxue; xen-devel > Subject: RE: [Xen-devel] VMX test report for Xen 4.4-unstable-C/S 27314 > > >>> On 12.08.13 at 05:43, "Liu, SongtaoX" <songtaox.liu@intel.com> wrote: > >> >>> On 08.08.13 at 09:13, "Ren, Yongjie" <yongjie.ren@intel.com> wrote: > >> > 2. device pass-through works even if VT-d is disabled in BIOS > >> > > >> > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1 > >> > 866 > >> > >> Are you sure this was seen with 27314:e6ca87e13937? I ask because > >> 27204:06c2f6031aff is supposed to be taking care of this (and it did > >> in my > > and - I > >> think - also in others'' testing). To make things even less clear, the > >> bug > > itself > >> mentions 27203 and 27214... > >> > > Yes, it also exists in c/s 27204:06c2f6031aff, 27324:e9c802e5acc9. > > vt-d function had been disabled in BIOS, with "iommu=0" in grub line, > > "xl pci-assignable-add", "xl pci-attach" still works, and could > > passthrough to hvm guest, but the attached PCI device could not get > > IP. > > Please provide proof of that (logs + xl output) - I don''t really trust this given the > already mentioned confusion about changesets in the bug vs the report here. > > JanI find this issue exist in IVT-EP but not exist in SNB-EP or HSW desktop. Here are the logs about this issue, include qemu log, "dmesg" and "xl dmesg" log of dom0, "dmesg" log of guest, as the attachment. Yongwei(Terrence) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 13.08.13 at 07:45, "Xu, YongweiX" <yongweix.xu@intel.com> wrote: >> From: Jan Beulich [mailto:JBeulich@suse.com] >> >>> On 12.08.13 at 05:43, "Liu, SongtaoX" <songtaox.liu@intel.com> wrote: >> >> >>> On 08.08.13 at 09:13, "Ren, Yongjie" <yongjie.ren@intel.com> wrote: >> >> > 2. device pass-through works even if VT-d is disabled in BIOS >> >> > >> >> > http://bugzilla-archived.xenproject.org//bugzilla/show_bug.cgi?id=1 >> >> > 866 >> >> >> >> Are you sure this was seen with 27314:e6ca87e13937? I ask because >> >> 27204:06c2f6031aff is supposed to be taking care of this (and it did >> >> in my >> > and - I >> >> think - also in others'' testing). To make things even less clear, the >> >> bug >> > itself >> >> mentions 27203 and 27214... >> >> >> > Yes, it also exists in c/s 27204:06c2f6031aff, 27324:e9c802e5acc9. >> > vt-d function had been disabled in BIOS, with "iommu=0" in grub line, >> > "xl pci-assignable-add", "xl pci-attach" still works, and could >> > passthrough to hvm guest, but the attached PCI device could not get >> > IP. >> >> Please provide proof of that (logs + xl output) - I don''t really trust this given the >> already mentioned confusion about changesets in the bug vs the report here. > > I find this issue exist in IVT-EP but not exist in SNB-EP or HSW desktop.Now that''s really odd of course. And it means that someone with access to an affected system will need to do some investigation at least. Jan