http://permalink.gmane.org/gmane.comp.emulators.xen.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160549 <pre>Hi Ian, can we push multiboot v2 support for Xen/ARM still into 4.3? It looks like it can coexists with zImage in the same binary - the multiboot structure can be put just behind the zImage header and the code can determine how it has been started: zImage bootloaders clears r0, multiboot one's would set r0 to the MB magic. I will sketch a patch tomorrow, just wondering if we can have this in 4.3 to have a sane booting protocol from the very beginning. Of course bootloaders need to be enabled also, I could take care of the u-boot port. Regards, Andre. </pre> Andre Przywara 2013-05-23T22:38:46 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160548 <pre> Hi, Interestingly Linux/ARM does not seem to expect a parameter to earlyprintk, the actual device to use is hardcoded in arch/arm/include/debug/&lt;mach&gt;.S and earlyprintk is just a switch. So earlyprintk=xen is broken anyway ;-) But using bootargs for Dom0 could just be a fallback, so what about: if xen,xen-bootargs is provided: use it for Xen, else use ""; if xen,dom0-bootargs is provided: use it for Dom0, else if bootargs is provided: use that for Dom0 write Dom0 cmdline into chosen/bootargs in Dom0's dtb And is there a need for the "xen," prefix? I thought that this syntax is only needed for the compatible property, no? So eventually there could be one dtb to rule them all: chosen { xen,xen-bootargs = "..."; xen,dom0-bootargs = "..."; bootargs = "..."; } My concern is not so much about the bootloader's understanding of the dtb, but more about the vendor provided one, which one would expect to be in flash ROM, for instance. We can provide only one here. Will send a patch tomorrow. Regards,</pre> Andre Przywara 2013-05-23T22:27:42 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160547 <pre> Actually that is not true, in fact in the example above the only difference is earlyprintk=xenboot that is just a debug option. </pre> Stefano Stabellini 2013-05-23T21:04:45 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160546 <pre>Do not assume that we will only receive interrupts at a rate of nmi_hz. On a test system being debugged, I observed a PCI SERR being continuously asserted without the SERR bit being set. The result was Xen "exceeding" a 300 second timeout within 1 second. Change the nmi_watchdog_tick() timecounting to use timestamps rather than a rate calculated from nmi_hz (which itself has been seen to deviate on some systems due to Turbo/Pstates). Also, move the comment to a more appropriate place (as we would expect to enter the old if() block once a second anyway), and fix up two trailing whitespace issues. Signed-off-by: Andrew Cooper &lt;andrew.cooper3&lt; at &gt;citrix.com&gt; diff -r c6fb586f83a0 -r ebb0070be9fd xen/arch/x86/nmi.c --- a/xen/arch/x86/nmi.c +++ b/xen/arch/x86/nmi.c &lt; at &gt;&lt; at &gt; -396,7 +396,7 &lt; at &gt;&lt; at &gt; static struct notifier_block cpu_nmi_nfb }; static DEFINE_PER_CPU(unsigned int, last_irq_sums); -static DEFINE_PER_CPU(unsigned int, alert_counter); +static DEFINE_PER_CPU(s_time_t, last_irq_change); static atomic_t watchdog</pre> Andrew Cooper 2013-05-23T20:32:06 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160545 <pre>Yes, looks good. :) Thanks, Ian. </pre> Ian Murray 2013-05-23T19:23:54 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160544 <pre>flight 18007 xen-4.1-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18007/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-armhf 4 xen-build fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-i386-i386-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13</pre> xen.org 2013-05-23T19:22:10 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160543 <pre>On 05/23/13 02:06, Roger Pau Monné wrote: Looks like there's agreement about the cpuids here. Anything else I should try testing? SMAP type=01 base=0000000000000000 len=000000000009e000 SMAP type=02 base=000000000009e000 len=0000000000002000 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=00000000eff00000 SMAP type=02 base=00000000fc000000 len=0000000004000000 SMAP type=01 base=0000000100000000 len=0000003c19000000 Table 'FACP' at 0xfc014980 Table 'APIC' at 0xfc014a80 APIC: Found table at 0xfc014a80 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 1: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 2: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 3: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 8 ACPI ID 4: enabled SMP: Added CPU 8 (AP) MADT: Found CPU APIC ID 10 ACPI ID 5: enabled SMP: Added CPU 10 (AP) MAD</pre> Colin Percival 2013-05-23T19:09:12 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160542 <pre>On Wed, May 22, 2013 at 4:10 PM, Konrad Rzeszutek Wilk &lt;konrad.wilk&lt; at &gt;oracle.com&gt; wrote: First, thank you so much for getting back to me, it's really appreciated. At this point I've forgotten if I did this with Wheezy on Wheezy, and what the result was. I'll have to test using the 3.2 kernel on the domU Debian Squeeze and get back to you. I should be able to do that early next week. </pre> Anthony Sheetz 2013-05-23T18:19:50 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160541 <pre> Can you recheck this on stock HEAD? From your description this looks like a rather old bug seen with 8.2 or above and XCP (referenced in PR kern/164630). You can trigger it when e.g. booting with empty cdrom. </pre> Sergey Kandaurov 2013-05-23T16:48:15 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160540 <pre>Hi, Just remove this line (or pointing to a similar file from the template: (It's part of the disks definition: Jeroen. On 23 May 2013, at 19:02, Outback Dingo &lt;outbackdingo&lt; at &gt;gmail.com&gt; wrote: </pre> Jeroen van der Ham 2013-05-23T17:22:27 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160539 <pre>Hello, I've pushed a new branch, pvhvm_v10 that contains a PV IPI implementation for both amd64 and i386. I've also updated the wiki to point to the pvhvm_v10 branch: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v10 I've updated my tree to latest HEAD, so now branch pvhvm_v10 is on top of this commit: commit b44da0fb82647f2cfb06f65a6695c7e36c98828c Author: gber &lt;gber&lt; at &gt;FreeBSD.org&gt; Date: Thu May 23 12:24:46 2013 +0000 Rework and organize pmap_enter_locked() function. pmap_enter_locked() implementation was very ambiguous and confusing. Rearrange it so that each part of the mapping creation is separated. Avoid walking through the redundant conditions. Extract vector_page specific PTE setup from normal PTE setting. Submitted by: Zbigniew Bodek &lt;zbb&lt; at &gt;semihalf.com&gt; Sponsored by: The FreeBSD Foundation, Semihalf Thanks for the testing, Roger. </pre> Roger Pau Monné 2013-05-23T17:41:50 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160538 <pre> Thanks, but this is XCP not a generic XEN server where there are vm config files under /etc/xen/ in XCP they dont exists _______________________________________________ Xen-devel mailing list Xen-devel&lt; at &gt;lists.xen.org http://lists.xen.org/xen-devel </pre> Outback Dingo 2013-05-23T17:29:34 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160537 <pre>Ok, sounds like I was misremembering. I've looked more thoroughly at the various threads and at the patches that come with them and it turned out that Dulloor's Aug 2010 series is about NUMA for HVM guests as well. That is to say: For HVM guest NUMA, here's what we have had: - July 2008, from Andre: http://lists.xen.org/archives/html/xen-devel/2008-07/msg00582.html - February 2010, from Andre: http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00279.html - August 2010, from Dulloor: http://lists.xen.org/archives/html/xen-devel/2010-08/msg00008.html For PV guest NUMA, here's what we have had: - April 2010, from Dulloor: http://lists.xen.org/archives/html/xen-devel/2010-04/msg00103.html - February 2010, from Dulloor: http://old-list-archives.xenproject.org/archives/html/xen-devel/2010-02/msg00630.html - from Dulloor (implementing some kind of NUMA aware ballooning): http://lists.xen.org/archives/html/xen-devel/2010-04/txtHhAq92jBSc.txt Also, still for PV NUMA, this message (and of </pre> Dario Faggioli 2013-05-23T17:21:21 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160536 <pre>flight 18006 xen-4.2-testing real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18006/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: build-armhf 4 xen-build fail never pass test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-i386-i386-xl-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 13 </pre> xen.org 2013-05-23T17:06:47 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160535 <pre> great how does one go about disabling the cdrom, i get some disk parameters needs to be removed from the vm template before boot _______________________________________________ Xen-devel mailing list Xen-devel&lt; at &gt;lists.xen.org http://lists.xen.org/xen-devel </pre> Outback Dingo 2013-05-23T17:02:45 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160534 <pre> From what I've read on the list, it seems like you cannot boot the PVHVM kernel if you have a cdrom attached to the guest, could you try disabling the cdrom and booting again? </pre> Roger Pau Monné 2013-05-23T16:48:16 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160533 <pre> on boot after ugen0.2: &lt;QEMU 0.10.2&gt; at usbus0 run_interrupt_driven_hooks: still waiting after 60 seconds for xenbus_nop_confighook_cb run_interrupt_driven_hooks: still waiting after 120 seconds for xenbus_nop_confighook_cb run_interrupt_driven_hooks: still waiting after 180 seconds for xenbus_nop_confighook_cb run_interrupt_driven_hooks: still waiting after 240 seconds for xenbus_nop_confighook_cb run_interrupt_driven_hooks: still waiting after 300 seconds for xenbus_nop_confighook_cb panic: run_interrupt_driven_confighooks: waited too long cpuid = 0 KDB: enter: panic [ thread pid 0 tid 100000 ] Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip) db&gt; _______________________________________________ _______________________________________________ Xen-devel mailing list Xen-devel&lt; at &gt;lists.xen.org http://lists.xen.org/xen-devel </pre> Outback Dingo 2013-05-23T16:30:32 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160532 <pre>flight 18003 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18003/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-pvops 4 kernel-build fail REGR. vs. 12557 Tests which did not succeed, but are not blocking: test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 xen-build-check(1) bloc</pre> xen.org 2013-05-23T16:14:38 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160531 <pre> Unless qxl is useable with sse2 disabled, there's no benefit to having the QXL fix in 4.3. The only reason Anthony might do it is to be able to take it off his queue of things to do later -- I would leave it to his discretion. -George </pre> George Dunlap 2013-05-23T16:10:51 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160530 <pre> Well that's good news anyway -- it means that qxl as a feature is actually within reach. :-) Can you try it just with sse2 disabled? I'm afraid the code is terribly complicated. If I could have hacked together a quick patch I would have already done so. :-) -George _______________________________________________ Xen-devel mailing list Xen-devel&lt; at &gt;lists.xen.org http://lists.xen.org/xen-devel </pre> George Dunlap 2013-05-23T16:07:09 http://permalink.gmane.org/gmane.comp.emulators.xen.devel/160529 <pre> It's good to hear QXL actually works with Xen qemu-upstream, (in the future) when the SSE issue is fixed! How about Anthony's patch for QXL.. Is that OK for for Xen 4.3, or should that wait for 4.4 ? </pre> Pasi Kärkkäinen 2013-05-23T15:10:19 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.emulators.xen.devel