Xu, Jiajun
2009-Sep-28 13:20 UTC
[Xen-devel] Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
Hi all, This is our bi-weekly test report for Xen-unstable tree. There are 4 new bugs found this two weeks. Live Migration issue is fixed. There are some EPT related bugs found with latest xen. New Bugs (4): ====================================================================1. Booting guest with device assigned & EPT enabled cause xen crash http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1518 2. VF can not get IP in Guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1517 3. memtest86 cause hvm crash with EPT violation http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1516 4. VFs cannot be created due to intremap index exceeding limit http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1515 Fixed Bugs (4): ====================================================================1. latest 64-bit pv-ops dom0 can not boot up on Xeon 5400 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1508 2. HVM guest Live migration fail on the latest pvops xen http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1509 3. Live migration clobbers VM filesystem http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1494 4. VF can not be enabled in pv-ops dom0 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1499 Old P1 Bugs (4): ====================================================================1. stubdom based guest hangs at starting when using qcow image. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1372 2. Linux guest boots up very slow with SDL rendering http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1478 3. [vt-d]when assign 82557 NIC to HVM, HVM hang http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1493 4. Dom0 S3 will cause system reboot on Xeon 5400 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1501 Old P2 Bugs (13) ====================================================================1. T state control failed http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1451 2. Failed to install FC10 http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1461 3. Two onboard 82576 NICs assigned to HVM guest cannot work stable if use INTx interrupt. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1459 4. E1000e NIC failed in FC10 guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1458 5. stubdom based guest hangs when assigning hdc to it. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1373 6. [stubdom]The xm save command hangs while saving <Domain-dm>. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1377 7. [stubdom] cannot restore stubdom based domain. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1378 8. [VT-d] Winxp guest does not recognize the hot-add NIC on Nehalem-EP http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1498 9. [vt-d]Guest print repeated characters using assigned USB keyboard http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1502 10. [vt-d]the assigned USB device does not work when hot-plug the real device http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1503 11. [vt-d]USB mouse/keyboard device has poor performance in guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1504 12. [vt-d]USB EHCI can not be assign to guest http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1505 13. Pv-ops dom0 can not boot up on Core i7 platform with cpuidle enabled http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1510 Xen Info: ===========================================================================xen-changeset: 20255:623aa5c2eaa4 pvops git: commit b6ba0160515df96cf572f5160c471b65f5f37045 Merge: 697ebdf... d84c11c... Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> ioemu git: commit 743edef44f1d0da792aeb38a33bf468a4596f730 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Wed Sep 23 15:07:47 2009 +0100 Test Environment: =========================================================================Service OS : Red Hat Enterprise Linux Server release 5.1 (Tikanga) Hardware : Stoakley 32e Summary Test Report of Last Session ==================================================================== Total Pass Fail NoResult Crash ====================================================================vtd_ept_vpid 10 7 3 0 0 control_panel_ept_vpid 13 10 3 0 0 ras_ept_vpid 1 1 0 0 0 gtest_ept_vpid 22 21 1 0 0 acpi_ept_vpid 2 2 0 0 0 ====================================================================vtd_ept_vpid 10 7 3 0 0 :one_pcie_up_nomsi_64_g3 1 1 0 0 0 :two_dev_smp_nomsi_64_g3 1 0 1 0 0 :two_dev_scp_64_g32e 1 0 1 0 0 :lm_pcie_up_64_g32e 1 1 0 0 0 :lm_pcie_up_xp_nomsi_64_ 1 1 0 0 0 :two_dev_smp_64_g32e 1 0 1 0 0 :one_pcie_scp_64_g32e 1 1 0 0 0 :hp_pcie_up_nomsi_64_g32 1 1 0 0 0 :lm_pci_smp_nomsi_64_g32 1 1 0 0 0 :one_pcie_smp_64_g32e 1 1 0 0 0 control_panel_ept_vpid 13 10 3 0 0 :XEN_1500M_guest_64_g32e 1 1 0 0 0 :XEN_256M_guest_64_gPAE 1 1 0 0 0 :XEN_256M_xenu_64_gPAE 1 1 0 0 0 :XEN_LM_Continuity_64_g3 1 1 0 0 0 :XEN_LM_SMP_64_g32e 1 0 1 0 0 :XEN_vmx_vcpu_pin_64_g32 1 1 0 0 0 :XEN_linux_win_64_g32e 1 0 1 0 0 :XEN_SR_Continuity_64_g3 1 1 0 0 0 :XEN_vmx_2vcpu_64_g32e 1 1 0 0 0 :XEN_1500M_guest_64_gPAE 1 1 0 0 0 :XEN_two_winxp_64_g32e 1 0 1 0 0 :XEN_256M_guest_64_g32e 1 1 0 0 0 :XEN_SR_SMP_64_g32e 1 1 0 0 0 ras_ept_vpid 1 1 0 0 0 :cpu_online_offline_64_g 1 1 0 0 0 gtest_ept_vpid 22 21 1 0 0 :boot_up_noacpi_win2k_64 1 1 0 0 0 :boot_up_acpi_win2k_64_g 1 1 0 0 0 :reboot_xp_64_g32e 1 1 0 0 0 :boot_solaris10u5_64_g32 1 1 0 0 0 :boot_up_vista_64_g32e 1 1 0 0 0 :boot_indiana_64_g32e 1 1 0 0 0 :boot_up_acpi_xp_64_g32e 1 1 0 0 0 :boot_smp_acpi_xp_64_g32 1 1 0 0 0 :boot_up_acpi_64_g32e 1 1 0 0 0 :boot_up_win2008_64_g32e 1 1 0 0 0 :boot_base_kernel_64_g32 1 1 0 0 0 :boot_up_acpi_win2k3_64_ 1 1 0 0 0 :kb_nightly_64_g32e 1 1 0 0 0 :boot_nevada_64_g32e 1 1 0 0 0 :ltp_nightly_64_g32e 1 0 1 0 0 :boot_fc9_64_g32e 1 1 0 0 0 :boot_smp_vista_64_g32e 1 1 0 0 0 :boot_smp_win2008_64_g32 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_rhel5u1_64_g32e 1 1 0 0 0 :boot_smp_acpi_win2k_64_ 1 1 0 0 0 :reboot_fc6_64_g32e 1 1 0 0 0 acpi_ept_vpid 2 2 0 0 0 :hvm_s3_smp_sr_64_g32e 1 1 0 0 0 :hvm_s3_smp_64_g32e 1 1 0 0 0 ====================================================================Total 48 41 7 0 0 Service OS : Red Hat Enterprise Linux Server release 5.1 (Tikanga) Hardware : NHM-HEDT 32e Summary Test Report of Last Session ==================================================================== Total Pass Fail NoResult Crash ====================================================================ras_ept_vpid 1 1 0 0 0 control_panel_ept_vpid 13 13 0 0 0 gtest_ept_vpid 22 21 1 0 0 acpi_ept_vpid 2 2 0 0 0 ====================================================================ras_ept_vpid 1 1 0 0 0 :cpu_online_offline_64_g 1 1 0 0 0 control_panel_ept_vpid 13 13 0 0 0 :XEN_1500M_guest_64_g32e 1 1 0 0 0 :XEN_256M_guest_64_gPAE 1 1 0 0 0 :XEN_256M_xenu_64_gPAE 1 1 0 0 0 :XEN_LM_Continuity_64_g3 1 1 0 0 0 :XEN_LM_SMP_64_g32e 1 1 0 0 0 :XEN_vmx_vcpu_pin_64_g32 1 1 0 0 0 :XEN_linux_win_64_g32e 1 1 0 0 0 :XEN_SR_Continuity_64_g3 1 1 0 0 0 :XEN_vmx_2vcpu_64_g32e 1 1 0 0 0 :XEN_1500M_guest_64_gPAE 1 1 0 0 0 :XEN_two_winxp_64_g32e 1 1 0 0 0 :XEN_256M_guest_64_g32e 1 1 0 0 0 :XEN_SR_SMP_64_g32e 1 1 0 0 0 gtest_ept_vpid 22 21 1 0 0 :boot_up_acpi_win2k_64_g 1 1 0 0 0 :boot_up_noacpi_win2k_64 1 1 0 0 0 :reboot_xp_64_g32e 1 1 0 0 0 :boot_solaris10u5_64_g32 1 1 0 0 0 :boot_up_vista_64_g32e 1 1 0 0 0 :boot_indiana_64_g32e 1 1 0 0 0 :boot_up_acpi_xp_64_g32e 1 1 0 0 0 :boot_smp_acpi_xp_64_g32 1 1 0 0 0 :boot_up_acpi_64_g32e 1 1 0 0 0 :boot_base_kernel_64_g32 1 1 0 0 0 :boot_up_win2008_64_g32e 1 0 1 0 0 :boot_up_acpi_win2k3_64_ 1 1 0 0 0 :kb_nightly_64_g32e 1 1 0 0 0 :boot_nevada_64_g32e 1 1 0 0 0 :boot_smp_vista_64_g32e 1 1 0 0 0 :boot_fc9_64_g32e 1 1 0 0 0 :ltp_nightly_64_g32e 1 1 0 0 0 :boot_smp_win2008_64_g32 1 1 0 0 0 :boot_smp_acpi_win2k3_64 1 1 0 0 0 :boot_rhel5u1_64_g32e 1 1 0 0 0 :boot_smp_acpi_win2k_64_ 1 1 0 0 0 :reboot_fc6_64_g32e 1 1 0 0 0 acpi_ept_vpid 2 2 0 0 0 :hvm_s3_smp_sr_64_g32e 1 1 0 0 0 :hvm_s3_smp_64_g32e 1 1 0 0 0 ====================================================================Total 38 37 1 0 0 Best Regards, Jiajun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Xu, Jiajun
2009-Sep-30 01:15 UTC
[Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
> 1. Booting guest with device assigned & EPT enabled cause xen crash > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1518For the above bug, it''s a regression which does not exist in xen c/s 20187. Could anyone help to fix it? It''s likely that the issue is introduced by the "pod for EPT" patches (20191~20197). On Monday, September 28, 2009 9:21 PM xen-devel-bounces@lists.xensource.com wrote:> Hi all, > > This is our bi-weekly test report for Xen-unstable tree. There > are 4 new bugs found this two weeks. Live Migration issue is > fixed. There are some EPT related bugs found with latest xen. > > New Bugs (4): > ====================================================================> 1. Booting guest with device assigned & EPT enabled cause xen crash > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1518 > 2. VF can not get IP in Guest > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1517 > 3. memtest86 cause hvm crash with EPT violation > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1516 > 4. VFs cannot be created due to intremap index exceeding limit > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1515 > > > Fixed Bugs (4): > ====================================================================> 1. latest 64-bit pv-ops dom0 can not boot up on Xeon 5400 > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1508 > 2. HVM guest Live migration fail on the latest pvops xen > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1509 > 3. Live migration clobbers VM filesystem > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1494 > 4. VF can not be enabled in pv-ops dom0 > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1499 > > > Old P1 Bugs (4): > ====================================================================> 1. stubdom based guest hangs at starting when using qcow image. > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1372 > 2. Linux guest boots up very slow with SDL rendering > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1478 > 3. [vt-d]when assign 82557 NIC to HVM, HVM hang > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1493 > 4. Dom0 S3 will cause system reboot on Xeon 5400 > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1501 > > > Old P2 Bugs (13) > ====================================================================> 1. T state control failed > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1451 > 2. Failed to install FC10 > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1461 > 3. Two onboard 82576 NICs assigned to HVM guest cannot work > stable if use INTx interrupt. > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1459 > 4. E1000e NIC failed in FC10 guest > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1458 > 5. stubdom based guest hangs when assigning hdc to it. > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1373 > 6. [stubdom]The xm save command hangs while saving <Domain-dm>. > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1377 > 7. [stubdom] cannot restore stubdom based domain. > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1378 > 8. [VT-d] Winxp guest does not recognize the hot-add NIC on Nehalem-EP > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1498 > 9. [vt-d]Guest print repeated characters using assigned USB keyboard > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1502 > 10. [vt-d]the assigned USB device does not work when hot-plug > the real device > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1503 > 11. [vt-d]USB mouse/keyboard device has poor performance in guest > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1504 > 12. [vt-d]USB EHCI can not be assign to guest > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1505 > 13. Pv-ops dom0 can not boot up on Core i7 platform with > cpuidle enabled > http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1510 > > > Xen Info: > ==============================================================> ============= xen-changeset: 20255:623aa5c2eaa4 > > pvops git: > commit b6ba0160515df96cf572f5160c471b65f5f37045 > Merge: 697ebdf... d84c11c... > Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> > > ioemu git: > commit 743edef44f1d0da792aeb38a33bf468a4596f730 > Author: Ian Jackson <ian.jackson@eu.citrix.com> > Date: Wed Sep 23 15:07:47 2009 +0100 > > Test Environment: > ==============================================================> =========== Service OS : Red Hat Enterprise Linux Server release 5.1 > (Tikanga) Hardware : Stoakley > > 32e Summary Test Report of Last Session > ====================================================================> Total Pass Fail NoResult Crash > ====================================================================> vtd_ept_vpid 10 7 3 0 0 > control_panel_ept_vpid 13 10 3 0 0 > ras_ept_vpid 1 1 0 0 0 > gtest_ept_vpid 22 21 1 0 0 > acpi_ept_vpid 2 2 0 0 0 > ====================================================================> vtd_ept_vpid 10 7 3 0 0 >> one_pcie_up_nomsi_64_g3 1 1 0 0 0 >> two_dev_smp_nomsi_64_g3 1 0 1 0 0 >> two_dev_scp_64_g32e 1 0 1 0 0 >> lm_pcie_up_64_g32e 1 1 0 0 0 >> lm_pcie_up_xp_nomsi_64_ 1 1 0 0 0 >> two_dev_smp_64_g32e 1 0 1 0 0 >> one_pcie_scp_64_g32e 1 1 0 0 0 >> hp_pcie_up_nomsi_64_g32 1 1 0 0 0 >> lm_pci_smp_nomsi_64_g32 1 1 0 0 0 >> one_pcie_smp_64_g32e 1 1 0 0 0 > control_panel_ept_vpid 13 10 3 0 0 >> XEN_1500M_guest_64_g32e 1 1 0 0 0 >> XEN_256M_guest_64_gPAE 1 1 0 0 0 >> XEN_256M_xenu_64_gPAE 1 1 0 0 0 >> XEN_LM_Continuity_64_g3 1 1 0 0 0 >> XEN_LM_SMP_64_g32e 1 0 1 0 0 >> XEN_vmx_vcpu_pin_64_g32 1 1 0 0 0 >> XEN_linux_win_64_g32e 1 0 1 0 0 >> XEN_SR_Continuity_64_g3 1 1 0 0 0 >> XEN_vmx_2vcpu_64_g32e 1 1 0 0 0 >> XEN_1500M_guest_64_gPAE 1 1 0 0 0 >> XEN_two_winxp_64_g32e 1 0 1 0 0 >> XEN_256M_guest_64_g32e 1 1 0 0 0 >> XEN_SR_SMP_64_g32e 1 1 0 0 0 > ras_ept_vpid 1 1 0 0 0 >> cpu_online_offline_64_g 1 1 0 0 0 > gtest_ept_vpid 22 21 1 0 0 >> boot_up_noacpi_win2k_64 1 1 0 0 0 >> boot_up_acpi_win2k_64_g 1 1 0 0 0 >> reboot_xp_64_g32e 1 1 0 0 0 >> boot_solaris10u5_64_g32 1 1 0 0 0 >> boot_up_vista_64_g32e 1 1 0 0 0 >> boot_indiana_64_g32e 1 1 0 0 0 >> boot_up_acpi_xp_64_g32e 1 1 0 0 0 >> boot_smp_acpi_xp_64_g32 1 1 0 0 0 >> boot_up_acpi_64_g32e 1 1 0 0 0 >> boot_up_win2008_64_g32e 1 1 0 0 0 >> boot_base_kernel_64_g32 1 1 0 0 0 >> boot_up_acpi_win2k3_64_ 1 1 0 0 0 >> kb_nightly_64_g32e 1 1 0 0 0 >> boot_nevada_64_g32e 1 1 0 0 0 >> ltp_nightly_64_g32e 1 0 1 0 0 >> boot_fc9_64_g32e 1 1 0 0 0 >> boot_smp_vista_64_g32e 1 1 0 0 0 >> boot_smp_win2008_64_g32 1 1 0 0 0 >> boot_smp_acpi_win2k3_64 1 1 0 0 0 >> boot_rhel5u1_64_g32e 1 1 0 0 0 >> boot_smp_acpi_win2k_64_ 1 1 0 0 0 >> reboot_fc6_64_g32e 1 1 0 0 0 > acpi_ept_vpid 2 2 0 0 0 >> hvm_s3_smp_sr_64_g32e 1 1 0 0 0 >> hvm_s3_smp_64_g32e 1 1 0 0 0 > ====================================================================> Total 48 41 7 0 0 > > Service OS : Red Hat Enterprise Linux Server release 5.1 (Tikanga) > Hardware : NHM-HEDT > > 32e Summary Test Report of Last Session > ====================================================================> Total Pass Fail NoResult Crash > ====================================================================> ras_ept_vpid 1 1 0 0 0 > control_panel_ept_vpid 13 13 0 0 0 > gtest_ept_vpid 22 21 1 0 0 > acpi_ept_vpid 2 2 0 0 0 > ====================================================================> ras_ept_vpid 1 1 0 0 0 >> cpu_online_offline_64_g 1 1 0 0 0 > control_panel_ept_vpid 13 13 0 0 0 >> XEN_1500M_guest_64_g32e 1 1 0 0 0 >> XEN_256M_guest_64_gPAE 1 1 0 0 0 >> XEN_256M_xenu_64_gPAE 1 1 0 0 0 >> XEN_LM_Continuity_64_g3 1 1 0 0 0 >> XEN_LM_SMP_64_g32e 1 1 0 0 0 >> XEN_vmx_vcpu_pin_64_g32 1 1 0 0 0 >> XEN_linux_win_64_g32e 1 1 0 0 0 >> XEN_SR_Continuity_64_g3 1 1 0 0 0 >> XEN_vmx_2vcpu_64_g32e 1 1 0 0 0 >> XEN_1500M_guest_64_gPAE 1 1 0 0 0 >> XEN_two_winxp_64_g32e 1 1 0 0 0 >> XEN_256M_guest_64_g32e 1 1 0 0 0 >> XEN_SR_SMP_64_g32e 1 1 0 0 0 > gtest_ept_vpid 22 21 1 0 0 >> boot_up_acpi_win2k_64_g 1 1 0 0 0 >> boot_up_noacpi_win2k_64 1 1 0 0 0 >> reboot_xp_64_g32e 1 1 0 0 0 >> boot_solaris10u5_64_g32 1 1 0 0 0 >> boot_up_vista_64_g32e 1 1 0 0 0 >> boot_indiana_64_g32e 1 1 0 0 0 >> boot_up_acpi_xp_64_g32e 1 1 0 0 0 >> boot_smp_acpi_xp_64_g32 1 1 0 0 0 >> boot_up_acpi_64_g32e 1 1 0 0 0 >> boot_base_kernel_64_g32 1 1 0 0 0 >> boot_up_win2008_64_g32e 1 0 1 0 0 >> boot_up_acpi_win2k3_64_ 1 1 0 0 0 >> kb_nightly_64_g32e 1 1 0 0 0 >> boot_nevada_64_g32e 1 1 0 0 0 >> boot_smp_vista_64_g32e 1 1 0 0 0 >> boot_fc9_64_g32e 1 1 0 0 0 >> ltp_nightly_64_g32e 1 1 0 0 0 >> boot_smp_win2008_64_g32 1 1 0 0 0 >> boot_smp_acpi_win2k3_64 1 1 0 0 0 >> boot_rhel5u1_64_g32e 1 1 0 0 0 >> boot_smp_acpi_win2k_64_ 1 1 0 0 0 >> reboot_fc6_64_g32e 1 1 0 0 0 > acpi_ept_vpid 2 2 0 0 0 >> hvm_s3_smp_sr_64_g32e 1 1 0 0 0 >> hvm_s3_smp_64_g32e 1 1 0 0 0 > ====================================================================> Total 38 37 1 0 0 > > > Best Regards, > Jiajun > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-develBest Regards Jiajun _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Sep-30 06:57 UTC
Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
On 30/09/2009 02:15, "Xu, Jiajun" <jiajun.xu@intel.com> wrote:>> 1. Booting guest with device assigned & EPT enabled cause xen crash >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1518 > > For the above bug, it''s a regression which does not exist in xen c/s 20187. > Could anyone help to fix it? > > It''s likely that the issue is introduced by the "pod for EPT" patches > (20191~20197).It is caused by the addition of an assertion that p2m_is_locked_by_me in ept_sync_domain(). This was done because that function needs to be serialised, and we expected that anyone coming through set_p2m_entry() would have the p2m_lock held. So, we could ''fix'' by giving ept_sync_domain() its own lock, but my suspicion would be that any paths through the p2m code that are not holding the p2m_lock probably need to be fixed. Adjusting p2m entries without the lock held sounds racey to me. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Deegan
2009-Sep-30 09:08 UTC
Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
Hi, At 07:57 +0100 on 30 Sep (1254297424), Keir Fraser wrote:> On 30/09/2009 02:15, "Xu, Jiajun" <jiajun.xu@intel.com> wrote: > > >> 1. Booting guest with device assigned & EPT enabled cause xen crash > >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1518 > > > > For the above bug, it''s a regression which does not exist in xen c/s 20187. > > Could anyone help to fix it? > > > > It''s likely that the issue is introduced by the "pod for EPT" patches > > (20191~20197). > > It is caused by the addition of an assertion that p2m_is_locked_by_me in > ept_sync_domain(). This was done because that function needs to be > serialised, and we expected that anyone coming through set_p2m_entry() would > have the p2m_lock held.That''s a very good assumption - it''s the whole purpose of the p2m lock, in fact. And doubly so in the EPT code, which doesnt seem to take any care over concurrency at all.> So, we could ''fix'' by giving ept_sync_domain() its own lock, but my > suspicion would be that any paths through the p2m code that are not holding > the p2m_lock probably need to be fixed. Adjusting p2m entries without the > lock held sounds racey to me.The {set,clear}_mmio_p2m_entry functions that were added for Vt-D MMIO passthrough don''t seem to do any locking. (Actually, I don''t see why the mmio passthrough needs its own interface to the p2m at all.) Untested but obvious fix attached. Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Sep-30 09:20 UTC
Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
On 30/09/2009 10:08, "Tim Deegan" <Tim.Deegan@eu.citrix.com> wrote:>> So, we could ''fix'' by giving ept_sync_domain() its own lock, but my >> suspicion would be that any paths through the p2m code that are not holding >> the p2m_lock probably need to be fixed. Adjusting p2m entries without the >> lock held sounds racey to me. > > The {set,clear}_mmio_p2m_entry functions that were added for Vt-D MMIO > passthrough don''t seem to do any locking. (Actually, I don''t see why > the mmio passthrough needs its own interface to the p2m at all.) > Untested but obvious fix attached.I''d like Intel to test this before checkin, mainly to make sure it is complete enough. I have a feeling the vmx_set_uc_mode() function may also enter the p2m code without the hindrance of locking. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2009-Oct-01 00:53 UTC
RE: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
I''m still seeing the same assertion failure with this patch on my NHM EP system. (XEN) Xen call trace: (XEN) [<ffff82c4801b01a5>] ept_sync_domain+0x62/0x9c (XEN) [<ffff82c4801e559d>] ept_set_entry+0x6c1/0x7f6 (XEN) [<ffff82c4801e5905>] ept_change_entry_emt_with_range+0x233/0x25e (XEN) [<ffff82c4801b0209>] vmx_set_uc_mode+0x2a/0x5d (XEN) [<ffff82c4801959c8>] hvm_set_uc_mode+0x31/0x38 (XEN) [<ffff82c480195de1>] hvm_set_cr0+0x412/0x533 (XEN) [<ffff82c4801b2a4d>] vmx_vmexit_handler+0xe8f/0x1b48 (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 8: (XEN) Assertion ''(((get_cpu_info()->current_vcpu))->processor == (d->arch.p2m)-> locker)'' failed at vmx.c:1242 (XEN) **************************************** -----Original Message----- From: Tim Deegan [mailto:Tim.Deegan@citrix.com] Sent: Wednesday, September 30, 2009 2:08 AM To: Keir Fraser Cc: Xu, Jiajun; ''xen-devel@lists.xensource.com''; Xin, Xiaohui; George Dunlap; Kay, Allen M; Han, Weidong; Li, Xin; Nakajima, Jun Subject: Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0... Hi, At 07:57 +0100 on 30 Sep (1254297424), Keir Fraser wrote:> On 30/09/2009 02:15, "Xu, Jiajun" <jiajun.xu@intel.com> wrote: > > >> 1. Booting guest with device assigned & EPT enabled cause xen crash > >> http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1518 > > > > For the above bug, it''s a regression which does not exist in xen c/s 20187. > > Could anyone help to fix it? > > > > It''s likely that the issue is introduced by the "pod for EPT" > > patches (20191~20197). > > It is caused by the addition of an assertion that p2m_is_locked_by_me > in ept_sync_domain(). This was done because that function needs to be > serialised, and we expected that anyone coming through set_p2m_entry() > would have the p2m_lock held.That''s a very good assumption - it''s the whole purpose of the p2m lock, in fact. And doubly so in the EPT code, which doesnt seem to take any care over concurrency at all.> So, we could ''fix'' by giving ept_sync_domain() its own lock, but my > suspicion would be that any paths through the p2m code that are not > holding the p2m_lock probably need to be fixed. Adjusting p2m entries > without the lock held sounds racey to me.The {set,clear}_mmio_p2m_entry functions that were added for Vt-D MMIO passthrough don''t seem to do any locking. (Actually, I don''t see why the mmio passthrough needs its own interface to the p2m at all.) Untested but obvious fix attached. Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> Tim. -- Tim Deegan <Tim.Deegan@citrix.com> Principal Software Engineer, Citrix Systems (R&D) Ltd. [Company #02300071, SL9 0DZ, UK.] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-01 07:19 UTC
Re: [Xen-devel] RE: Biweekly VMX status report. Xen: #20255 & Xen0:#b6ba0...
On 01/10/2009 01:53, "Kay, Allen M" <allen.m.kay@intel.com> wrote:> I''m still seeing the same assertion failure with this patch on my NHM EP > system. > > (XEN) Xen call trace: > (XEN) [<ffff82c4801b01a5>] ept_sync_domain+0x62/0x9c > (XEN) [<ffff82c4801e559d>] ept_set_entry+0x6c1/0x7f6 > (XEN) [<ffff82c4801e5905>] ept_change_entry_emt_with_range+0x233/0x25e > (XEN) [<ffff82c4801b0209>] vmx_set_uc_mode+0x2a/0x5dYes, that''s the other optimistically lock-free call path I eyeballed. It needs fixing too. Hence why I''m waiting for a combined all-in-one fixup patch, else we''ll be trickling the fixes callpath-by-callpath. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel