Re: FreeBSD PVHVM call for testing
On 10/11/13 9:56 PM, Roger Pau Monné wrote: On 11/10/13 11:42, Eggert, Lars wrote: Hi, On May 13, 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. any idea if/when this code will be merged into -CURRENT? It's already in HEAD, and will hopefully be part of the 10 release. my testing On Amazon shows a noticeable slowdown from 9-stable. Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, On May 13, 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. any idea if/when this code will be merged into -CURRENT? Thanks, Lars signature.asc Description: Message signed with OpenPGP using GPGMail
Re: FreeBSD PVHVM call for testing
On 11/10/13 11:42, Eggert, Lars wrote: Hi, On May 13, 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. any idea if/when this code will be merged into -CURRENT? It's already in HEAD, and will hopefully be part of the 10 release. Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, After some more testing I thought it would be good to put this into production for my personal server. I've used pvhvm_v19 and built it without debugging options and installed it on a FreeBSD 9.1 system. I've run into some hiccups with 9.1 user land and a 10-CURRENT kernel, but that's all solvable[0]. My VPS has some very limited memory (256M), but I've compensated with swap space (1G) Now anytime I'm putting the system under stress, by building ports or by running a git clone on the kernel repository here, I'm seeing a lot of messages about swap_pager: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 132545, size: 4096 The system also becomes very sluggish and sometimes unresponsive. The weird thing was that one of these messages happened right after a reboot when I rebuilt an outdated port and on the main console was checking the swap memory: jeroen:~/ $ swapinfo [8:13:29] Device 1K-blocks UsedAvail Capacity /dev/ada0p2524288 2484 521804 0% /dev/md0 1048576 2364 1046212 0% Total 1572864 4848 1568016 0% swap_pager: indefinite wait buffer: bufobj: 0, blkno: 131424, size: 4096 Is anyone else seeing something similar? I certainly did not experience something like this on 9.0 with a XENHVM kernel. If necessary I can rebuild a kernel with debugging support and do some more recording of what is actually going on. Jeroen. [0]: I have edited bsd.port.mk to always apply the FBSD10_FIX, and for version checking I am running pkg version with UNAME_r=9.1-RELEASE. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 22/07/13 09:18, Jeroen van der Ham wrote: Hi, After some more testing I thought it would be good to put this into production for my personal server. I've used pvhvm_v19 and built it without debugging options and installed it on a FreeBSD 9.1 system. I've run into some hiccups with 9.1 user land and a 10-CURRENT kernel, but that's all solvable[0]. My VPS has some very limited memory (256M), but I've compensated with swap space (1G) Is your guest running a 32bit or a 64bit kernel? Could you also provide the config file used to launch your guest and the Xen and Dom0 kernel versions? Now anytime I'm putting the system under stress, by building ports or by running a git clone on the kernel repository here, I'm seeing a lot of messages about swap_pager: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 132545, size: 4096 The system also becomes very sluggish and sometimes unresponsive. The weird thing was that one of these messages happened right after a reboot when I rebuilt an outdated port and on the main console was checking the swap memory: jeroen:~/ $ swapinfo [8:13:29] Device 1K-blocks UsedAvail Capacity /dev/ada0p2524288 2484 521804 0% /dev/md0 1048576 2364 1046212 0% Total 1572864 4848 1568016 0% swap_pager: indefinite wait buffer: bufobj: 0, blkno: 131424, size: 4096 Is anyone else seeing something similar? Could you also try a HEAD XENHVM kernel (without my patches), to see if the issue is related to my changes or to some bug already present in HEAD? I certainly did not experience something like this on 9.0 with a XENHVM kernel. If necessary I can rebuild a kernel with debugging support and do some more recording of what is actually going on. Jeroen. [0]: I have edited bsd.port.mk to always apply the FBSD10_FIX, and for version checking I am running pkg version with UNAME_r=9.1-RELEASE. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, I have this running for a day or so now, but I'm noticing that the load averages seem a bit off: $ uptime 11:17AM up 17:14, 1 user, load averages: 0.31, 0.27, 0.21 This is for a clean install, with just enough installed to compile this kernel. In top I'm seeing that the machine is idling 98% of the time. But this does not correlate to the load displayed above. Jeroen. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 20/06/13 11:20, Jeroen van der Ham wrote: Hi, I have this running for a day or so now, but I'm noticing that the load averages seem a bit off: $ uptime 11:17AM up 17:14, 1 user, load averages: 0.31, 0.27, 0.21 This is for a clean install, with just enough installed to compile this kernel. In top I'm seeing that the machine is idling 98% of the time. But this does not correlate to the load displayed above. This is probably due to the fact that we are not properly accounting for blocked/runnable/offline time. Did you see the same when running the XENHVM kernel without my patches? Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 19 Jun 2013, at 13:34, Roger Pau Monné roger@citrix.com wrote: Could you provide the boot log of the DomU, backtrace, Xen version and Dom0 kernel version? I did not have a console attached when it rebooted, so I did not have a log of the initial boot. Now that I did, I see that it fails to mount its root volume. It had been running previously on pvhvm_v10 for about two weeks without problems. I updated my local git, and recompiled the kernel and rebooted. Then this happened. In order: Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2 r+6ff8d00-dirty: Tue Jun 18 12:55:16 CEST 2013 root@image01:/usr/obj/root/freebsd/sys/XENHVM amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. XEN: Hypervisor version 4.0 detected. CPU: Quad-Core AMD Opteron(tm) Processor 2374 HE (2200.07-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f42 Family = 0x10 Model = 0x4 Stepping = 2 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x80802001SSE3,CX16,POPCNT,HV AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x1f3LAHF,CMP,CR8,ABM,SSE4A,MAS,Prefetch real memory = 536870912 (512 MB) avail memory = 472260608 (450 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 random device not loaded; using insecure entropy ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-47 on motherboard kbd1 at kbdmux0 xen_et0: Xen PV Clock on motherboard Event timer XENTIMER frequency 10 Hz quality 950 Timecounter XENTIMER frequency 10 Hz quality 950 acpi0: Xen on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 32-bit timer at 3.579545MHz port 0x1f48-0x1f4b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc300-0xc30f at device 1.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 pci0: bridge at device 1.3 (no driver attached) vgapci0: VGA-compatible display mem 0xf000-0xf1ff,0xf300-0xf3000fff at device 2.0 on pci0 xenpci0: Xen Platform Device port 0xc000-0xc0ff mem 0xf200-0xf2ff irq 28 at device 3.0 on pci0 xenstore0: XenStore on xenpci0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) ppc0: Parallel port port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 orm0: ISA Option ROM at iomem 0xc9000-0xc97ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fdc0: No FDOUT register! Timecounters tick every 10.000 msec xenbusb_front0: Xen Frontend Devices on xenstore0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: QEMU QEMU DVD-ROM 0.10 Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [360385 x 2048 byte records] xn0: Virtual Network Interface at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:2f:b7:22 xn1: Virtual Network Interface at device/vif/1 on xenbusb_front0 xn1: Ethernet address: 00:16:3e:3e:64:c5 xenbusb_back0: Xen Backend Devices on xenstore0 xctrl0: Xen Control Device on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xn1: backend features: feature-sg feature-gso-tcp4 xbd0:
Re: FreeBSD PVHVM call for testing
On 19/06/13 14:16, Jeroen van der Ham wrote: On 19 Jun 2013, at 13:34, Roger Pau Monné roger@citrix.com wrote: Could you provide the boot log of the DomU, backtrace, Xen version and Dom0 kernel version? I did not have a console attached when it rebooted, so I did not have a log of the initial boot. Now that I did, I see that it fails to mount its root volume. It had been running previously on pvhvm_v10 for about two weeks without problems. I updated my local git, and recompiled the kernel and rebooted. Then this happened. In order: Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #2 r+6ff8d00-dirty: Tue Jun 18 12:55:16 CEST 2013 root@image01:/usr/obj/root/freebsd/sys/XENHVM amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. XEN: Hypervisor version 4.0 detected. CPU: Quad-Core AMD Opteron(tm) Processor 2374 HE (2200.07-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f42 Family = 0x10 Model = 0x4 Stepping = 2 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x80802001SSE3,CX16,POPCNT,HV AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x1f3LAHF,CMP,CR8,ABM,SSE4A,MAS,Prefetch real memory = 536870912 (512 MB) avail memory = 472260608 (450 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 random device not loaded; using insecure entropy ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-47 on motherboard kbd1 at kbdmux0 xen_et0: Xen PV Clock on motherboard Event timer XENTIMER frequency 10 Hz quality 950 Timecounter XENTIMER frequency 10 Hz quality 950 acpi0: Xen on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 32-bit timer at 3.579545MHz port 0x1f48-0x1f4b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc300-0xc30f at device 1.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 pci0: bridge at device 1.3 (no driver attached) vgapci0: VGA-compatible display mem 0xf000-0xf1ff,0xf300-0xf3000fff at device 2.0 on pci0 xenpci0: Xen Platform Device port 0xc000-0xc0ff mem 0xf200-0xf2ff irq 28 at device 3.0 on pci0 xenstore0: XenStore on xenpci0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: 16550 or compatible port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) ppc0: Parallel port port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 orm0: ISA Option ROM at iomem 0xc9000-0xc97ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fdc0: No FDOUT register! Timecounters tick every 10.000 msec xenbusb_front0: Xen Frontend Devices on xenstore0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: QEMU QEMU DVD-ROM 0.10 Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [360385 x 2048 byte records] xn0: Virtual Network Interface at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:2f:b7:22 xn1: Virtual Network Interface at device/vif/1 on xenbusb_front0 xn1: Ethernet address: 00:16:3e:3e:64:c5 xenbusb_back0: Xen Backend Devices on
Re: FreeBSD PVHVM call for testing
On 19 Jun 2013, at 14:20, Roger Pau Monné roger@citrix.com wrote: That's because Justin recently pushed a commit that changed the ad translation to ada, you should change your /etc/fstab to ada0p2. It's commit 526f3ad11acb296481215d7c2915b3f30f1844f6. Ah, you may want to update the wiki page also to warn for that. :) Jeroen. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, On 19 Jun 2013, at 18:15, Justin T. Gibbs gi...@freebsd.org wrote: I've never seen a kernel build take 2 hours, much less 2 hours *longer*. Are you talking about buildworld? It would be interesting to know your results building stable/9 sources in your 10 environment to see if this is just due to build bloat or a true performance regression. I copy/pasted the command from the wiki: # make kernel-toolchain make buildkernel KERNCONF=XENHVM make installkernel KERNCONF=XENHVM On the stable/9 I only did make buildkernel KERNCONF=XENHVM make installkernel KERNCONF=XENHVM I guess the kernel-toolchain takes a long time to build…and from what I can see it does a clean before rebuilding also. I'm doing the kernel-toolchain step only now and will report how long it took. Jeroen. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Jun 19, 2013, at 10:50 AM, Jeroen van der Ham jer...@dckd.nl wrote: Hi, On 19 Jun 2013, at 18:15, Justin T. Gibbs gi...@freebsd.org wrote: I've never seen a kernel build take 2 hours, much less 2 hours *longer*. Are you talking about buildworld? It would be interesting to know your results building stable/9 sources in your 10 environment to see if this is just due to build bloat or a true performance regression. I copy/pasted the command from the wiki: # make kernel-toolchain make buildkernel KERNCONF=XENHVM make installkernel KERNCONF=XENHVM On the stable/9 I only did make buildkernel KERNCONF=XENHVM make installkernel KERNCONF=XENHVM I guess the kernel-toolchain takes a long time to build…and from what I can see it does a clean before rebuilding also. I'm doing the kernel-toolchain step only now and will report how long it took. Jeroen. Oh. Without any parallelism (-j X), the build will take a really long time. Even with only one core, you'll get a large speedup by performing a parallel build since many steps of the build are I/O bound. -- Justin ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 10/06/13 16:48, Roger Pau Monné wrote: Hello, I've pushed a new branch, pvhvm_v14 that contains support for live migration. While there I've also rebased the changes on top of current HEAD, so now it contains the recent fixes to blkfront and netfront. http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v14 Hello, There where some issues with the previous branch (pvhvm_v14), I've pushed a new one (pvhvm_v16) that fixes the following bugs: * Make sure there are no IPIs in flight while the VM is migrated, having in-flight IPIs is a problem because on resume the event channels are re-initialized, so all pending events are lost, including IPIs. * Reset the clock after migration, this prevent clock drifts when the VM is migrated. * blkfront was not correctly freeing the old event channel port. The following two commits are needed for Xen: f8e8fd56bd7d5675e8331b4ec74bae76c9dbf24e x86/HVM: fix initialization of wallclock time for PVHVM on migration 32c864a35ece2c24a336d183869a546798a4b241 x86/vtsc: update vcpu_time in hvm_set_guest_time With this branch I've been able to successfully local migrate a busy VM 400 times consecutively. As usual, the branch can be found here: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v16 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Mon, Jun 10, 2013 at 10:48 AM, Roger Pau Monné roger@citrix.comwrote: Hello, I've pushed a new branch, pvhvm_v14 that contains support for live migration. While there I've also rebased the changes on top of current HEAD, so now it contains the recent fixes to blkfront and netfront. http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v14 looking at your master branch your 2 weeks behind current... so where did you rebase your changes to head, or are you referring to your HEAD, and not FreeBSD ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 10/06/13 17:09, Outback Dingo wrote: On Mon, Jun 10, 2013 at 10:48 AM, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: Hello, I've pushed a new branch, pvhvm_v14 that contains support for live migration. While there I've also rebased the changes on top of current HEAD, so now it contains the recent fixes to blkfront and netfront. http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v14 looking at your master branch your 2 weeks behind current... so where did you rebase your changes to head, or are you referring to your HEAD, and not FreeBSD No, my HEAD commit from FreeBSD master repository is from 3 days ago: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=commit;h=5311e12c931df9b67b64913670eab76a994317b9 This is the commit where I rebased my pvhvm_v14 branch. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, On 23 May 2013, at 19:41, Roger Pau Monné roger@citrix.com wrote: 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: I've been running a VM with this kernel for about a week now. It ran fine, until about 3:30 in the morning. The only thing I can see is the following cryptic messages in /var/log/messages, followed by a reboot of the system. May 29 23:42:30 image01 sshd[31227]: error: Received disconnect from 150.165.15.175: 11: Bye Bye [preauth] May 30 03:30:57 image01 kernel: . May 30 03:30:57 image01 ntpd[4436]: ntpd exiting on signal 15 May 30 03:30:57 image01 kernel: . May 30 03:30:58 image01 kernel: . May 30 03:31:00 image01 syslogd: exiting on signal 15 May 30 03:32:52 image01 syslogd: kernel boot file is /boot/kernel/kernel May 30 03:32:52 image01 kernel: Copyright (c) 1992-2013 The FreeBSD Project. May 30 03:32:52 image01 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 May 30 03:32:52 image01 kernel: The Regents of the University of California. All rights reserved. May 30 03:32:52 image01 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. I'm happy to help to gather more information, just tell me what you need. Jeroen. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 30/05/13 10:50, Jeroen van der Ham wrote: Hi, On 23 May 2013, at 19:41, Roger Pau Monné roger@citrix.com wrote: 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: I've been running a VM with this kernel for about a week now. It ran fine, until about 3:30 in the morning. The only thing I can see is the following cryptic messages in /var/log/messages, followed by a reboot of the system. May 29 23:42:30 image01 sshd[31227]: error: Received disconnect from 150.165.15.175: 11: Bye Bye [preauth] May 30 03:30:57 image01 kernel: . May 30 03:30:57 image01 ntpd[4436]: ntpd exiting on signal 15 May 30 03:30:57 image01 kernel: . May 30 03:30:58 image01 kernel: . May 30 03:31:00 image01 syslogd: exiting on signal 15 May 30 03:32:52 image01 syslogd: kernel boot file is /boot/kernel/kernel May 30 03:32:52 image01 kernel: Copyright (c) 1992-2013 The FreeBSD Project. May 30 03:32:52 image01 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 May 30 03:32:52 image01 kernel: The Regents of the University of California. All rights reserved. May 30 03:32:52 image01 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. I'm happy to help to gather more information, just tell me what you need. Hello Jeroen, So it looks like the system rebooted (but it was not a crash or a sporadic reboot? the kernel seems to be aware of the reboot request). It would be interesting if you could provide the output of the serial console when this happens, that might be helpful. Did you enable xenconsoled logging? Also, could you provide more info about your system, Xen version, what workload was the DomU running, Dom0 kernel version? ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, On 30 May 2013, at 11:04, Roger Pau Monné roger@citrix.com wrote: So it looks like the system rebooted (but it was not a crash or a sporadic reboot? the kernel seems to be aware of the reboot request). It would be interesting if you could provide the output of the serial console when this happens, that might be helpful. Did you enable xenconsoled logging? Unfortunately I did not. Also, could you provide more info about your system, Xen version, what workload was the DomU running, Dom0 kernel version? There was no one logged in at the time of the reboot according to the last log. I did do some sysbench tests during the day, but that was way before it rebooted. The only thing that could be running during that time was daily periodic. $ sudo xm info host : soleus01.soleus.nu release: 2.6.32-5-xen-amd64 version: #1 SMP Mon Oct 3 07:53:54 UTC 2011 machine: x86_64 nr_cpus: 8 nr_nodes : 2 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 2200 hw_caps: 178bf3ff:efd3fbff::1310:00802001::37ff: virt_caps : hvm total_memory : 65534 free_memory: 6866 node_to_cpu: node0:0-3 node1:4-7 node_to_memory : node0:3128 node1:3737 node_to_dma32_mem : node0:3128 node1:0 max_node_id: 1 xen_major : 4 xen_minor : 0 xen_extra : .1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : unavailable xen_commandline: placeholder dom0_mem=1852M cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10) cc_compile_by : waldi cc_compile_domain : debian.org cc_compile_date: Wed Jan 12 14:04:06 UTC 2011 xend_config_format : 4 $ uname -a Linux soleus01.soleus.nu 2.6.32-5-xen-amd64 #1 SMP Mon Oct 3 07:53:54 UTC 2011 x86_64 GNU/Linux Jeroen. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, On 30 May 2013, at 16:56, Outback Dingo outbackdi...@gmail.com wrote: first is this a public vm ? and if so who is?? May 29 23:42:30 image01 sshd[31227]: error: Received disconnect from 150.165.15.175: 11: Bye Bye [preauth] because it is after this potential ssh login attempt, so is this you, has there been a breach ? only thing i noticed, but it might be nothing. This VM is on a public IP indeed, and SSH connectivity is enabled. As with any publicly accessible host this then becomes the target of ssh scans. I included the message just to show that between it and the reboot nothing had been logged. AFAICT there has not been a breach, and I have not seen any indications at all that there may be one. Jeroen. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Wed, May 29, 2013 at 07:03:40PM +0200, Roger Pau Monné wrote: Hello, Thanks Matt and Colin for the testing and help! I've pushed yet another version, now it's branch pvhvm_v12, which I *think* should solve the issues with cpuid != acpi_id: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v12 Since I'm not able to reproduce the cpuid != acpi_id case, could you give it a try and report the results? Colin, can you build an AMI with this new kernel? [...] On 28/05/13 23:33, Colin Percival wrote: On a cc2.8xlarge EC2 instance, the lines which come after this are GEOM: new disk xbd1 GEOM: new disk xbd2 GEOM: new disk xbd3 GEOM: new disk xbd4 Trying to mount root from ufs:/dev/ad0a [rw]... start_init: trying /sbin/init and then the userland boot process; have you made any bug fixes after your pvhvm_v7 which would explain why tasting disks was hanging? I'm not sure I follow, did you found a regression from previous branches? i.e. it used to work with branch pvhvm_v6 and not pvhvm_v7? Colin was saying that his local change only moved the boot process a bit farther for cr1.8xlarge. Perhaps some of the other changes you made in the latest pvhvm_v12 branch will get the VM all the way up. --msw ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On 05/29/13 10:45, Roger Pau Monné wrote: Oh, sure, more changes where needed in order to get it to work, like using acpi_id to map the vcpu_info and perform the cpu bindings. Ah, that explains it. I looked at timer.c for other places where that change was needed but it didn't occur to me that the same problem would exist in other parts of the tree. On 29/05/13 19:22, Matt Wilson wrote: On Wed, May 29, 2013 at 07:03:40PM +0200, Roger Pau Monné wrote: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvhvm_v12 Colin, can you build an AMI with this new kernel? Done, ami-95177dfc in us-east-1. This is now booting successfully on cr1.8xlarge; are there any other instance types I should test? I don't know which Xen versions you have deployed across the entire fleet. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Fri, May 24, 2013 at 6:27 PM, Craig Rodrigues rodr...@crodrigues.orgwrote: On Thu, May 23, 2013 at 6:30 AM, Roger Pau Monné roger@citrix.com wrote: On 23/05/13 15:20, Jeroen van der Ham wrote: On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM You mention on that page that it is easier to install on 10.0-CURRENT snapshots. What are the issues with installing this on 9.1? Is it possible? I don't think it is recommended to use a HEAD (10) kernel with a 9.1 userland. You can always install a 9.1 and then do a full update with the source on my repository. Actually in FreeBSD, it is possible to run an older userland on a newer kernel, and a lot of effort is spent in preserving this type of backwards compatibility. So a 9.1 userland with a 10 kernel will work. However, running a newer userland on an older kernel is not guaranteed to work. So running a 10 userland with a 9.1 kernel will most likely not work. However, since you guys are doing very cutting edge stuff with 10-CURRENT, it is better that you do not waste time with 9.1. I recommend you start with a 10.0 CURRENT snapshot ISO and go from there. I am going through a similar setup exercise with a Google Summer of Code student where he needs to have a latest CURRENT system running in a VM. I wrote this blog post: http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/ for the steps how to do it. You can follow those steps to get bootstrapped with a working environment if it helps you out. Good luck. Any chance this will be backported to 9.X or 9-STABLE at least ?? -- Craig ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to freebsd-xen-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 24/05/13 12:11, Roger Pau Monné wrote: On 23/05/13 21:09, Colin Percival wrote: On 05/23/13 02:06, Roger Pau Monné wrote: On 22/05/13 22:03, Colin Percival wrote: Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with a panic -- console output below. I can get a backtrace and possibly even a dump if those would help. Thanks for the test, I've been using Xen 4.2 (and 4.3) without problems so far. By looking at the Xen code, the only reason the timer setup could return -22 (EINVAL), is that we try to set the timer for a different vCPU than the one we are running on. I've been able to boot a 32 vCPU DomU on my 8way box using Xen 4.2.1 (using both qemu-xen and qemu-xen-traditional device models), so I'm unsure if this could be due to some patch Amazon applies to Xen. Could you try the following patch and post the error message? I would like to see if the cpuid reported by kdb and the vCPU that we are trying to set the timer are the same. Looks like there's agreement about the cpuids here. Anything else I should try testing? Thanks for the test, this is what I expected. I'm a little bit out of ideas since I'm not able to reproduce this on upstream Xen 4.2. Without knowing what's happening inside the hypervisor it's hard to tell what's wrong. It would be interesting to try if the same happens with a Linux PVHVM (not PV) running on the same instance type. Hello Matt, Colin has found an issue on the FreeBSD PVHVM port that I haven't been able to reproduce using open source Xen, even when using the same version as the one reported by EC2. Is there anyway you could provide some help debugging this? Without seeing the Xen code that causes VCPUOP_set_singleshot_timer to return EINVAL it is quite hard to figure out what's happening inside the hypervisor. Thanks, Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Fri, May 24, 2013 at 03:21:54PM -0700, Craig Rodrigues wrote: On Fri, May 24, 2013 at 7:14 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Thu, May 23, 2013 at 07:41:50PM +0200, Roger Pau Monné wrote: 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: I feel a bit stupid to ask this, but how I install 'gmake'? Doing 'pkg_add -r gmake' tells me there is no package (perhaps I am using a too modern version of FreeBSD (FreeBSD-10.0-CURRENT-amd64-20130512-r250582-release.iso)? The Wiki mentions how to install git but that fails b/c it can't find gmake. For 10.0-CURRENT, not all the packages are available yet from the main FreeBSD.org ftp site. I am going through a similar setup issue with someone who has signed up for Google Summer of Code, and I need him to use close to the latest 10.0-CURRENT and have a usable system. I wrote this blog post for the student: http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/ Excellent! Thanks for the link. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On 05/28/13 12:18, Matt Wilson wrote: VCPUOP_set_singleshot_timer returns -EINVAL when: 1) the specified vCPU ID is out of range (0 or MAX_VIRT_CPUS) 2) the specified vCPU ID doesn't match the running vCPU. It seems that there is a confusion between the logical vCPU ID and the local APIC physical ID. [...] (XEN) Domain 1 (vcpu#16) VCPUOP_set_singleshot_timer specified vcpuid 1 [...] APIC: CPU 1 has ACPI ID 16 Thanks Matt! Looks like we need to pass our acpi_id to the Xen hypercall instead of our cpuid. Roger, changing the line int cpu = PCPU_GET(cpuid); to int cpu = PCPU_GET(acpi_id); in xentimer_et_start and xentimer_et_stop fixes this panic and gets me slightly further; the following lines are now added to the console output prior to the system appearing to hang: ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 4 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 5 vector 48 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 6 vector 48 ioapic0: routing intpin 28 (PCI IRQ 28) to lapic 7 vector 48 TSC timecounter discards lower 1 bit(s) Timecounter TSC-low frequency 1300024860 Hz quality -100 WARNING: WITNESS option enabled, expect reduced performance. On a cc2.8xlarge EC2 instance, the lines which come after this are GEOM: new disk xbd1 GEOM: new disk xbd2 GEOM: new disk xbd3 GEOM: new disk xbd4 Trying to mount root from ufs:/dev/ad0a [rw]... start_init: trying /sbin/init and then the userland boot process; have you made any bug fixes after your pvhvm_v7 which would explain why tasting disks was hanging? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Tue, May 28, 2013 at 6:05 PM, Craig Rodrigues rodr...@crodrigues.orgwrote: On Tue, May 28, 2013 at 8:21 AM, Outback Dingo outbackdi...@gmail.comwrote: On Fri, May 24, 2013 at 6:27 PM, Craig Rodrigues rodr...@crodrigues.orgwrote: I wrote this blog post: http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/ for the steps how to do it. You can follow those steps to get bootstrapped with a working environment if it helps you out. Good luck. Any chance this will be backported to 9.X or 9-STABLE at least ?? I wrote a blog post specifically for installing 10-CURRENT from a snapshot ISO and getting bootstrapped from there, to help the Google Summer of Code Student that I am mentoring. What specifically do you want to be backported to 9-STABLE? Yes Ive seen the post, however we have a hard requirement for 9-STABLE for some development work we are currently involved in. And I would prefer not to move our current infrastructure for development to CURRENT. A major portion of our development environment is based on XEN for testing and development. Therefor we realize PVHVM is a work in progress, and we have built some VMs from it, they run exceptionally well, However our build environments refuse to build 9-STABLE on CURRENT PVHVM, or 10-CURRENT. Lastly Im sure theres a ton of users who would like to see this in 9.x or 9-STABLE -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Tue, May 28, 2013 at 7:09 PM, Craig Rodrigues rodr...@crodrigues.orgwrote: On Tue, May 28, 2013 at 3:43 PM, Outback Dingo outbackdi...@gmail.comwrote: I wrote a blog post specifically for installing 10-CURRENT from a snapshot ISO and getting bootstrapped from there, to help the Google Summer of Code Student that I am mentoring. What specifically do you want to be backported to 9-STABLE? Yes Ive seen the post, however we have a hard requirement for 9-STABLE for some development work we are currently involved in. And I would prefer not to move our current infrastructure for development to CURRENT. A major portion of our development environment is based on XEN for testing and development. Therefor we realize PVHM is a work in progress, and we have built some VMs from it, they run exceptionally well, However our build environments refuse to build 9-STABLE on CURRENT PVHVM, or 10-CURRENT. Lastly Im sure theres a ton of users who would like to see this in 9.x or 9-STABLE OK, I misunderstood you since you responded in the thread and quoted some of my post. My blog post has nothing relevant to Xen and PVHM, and is specific to setting up a Google Summer of Code student on a 10-CURRENT environment. The FreeBSD Xen and PVHM developers will need to provide the details about their plans to merge their changes to the 9-STABLE branch. that's something which I am not familiar with. If we can get a diff of the work done against the master Id be happy to help backporting and testing -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Tue, May 28, 2013 at 06:15:00PM +0200, Roger Pau Monné wrote:
On 24/05/13 12:11, Roger Pau Monné wrote:
Thanks for the test, this is what I expected. I'm a little bit out of
ideas since I'm not able to reproduce this on upstream Xen 4.2. Without
knowing what's happening inside the hypervisor it's hard to tell what's
wrong. It would be interesting to try if the same happens with a Linux
PVHVM (not PV) running on the same instance type.
Hello Matt,
Colin has found an issue on the FreeBSD PVHVM port that I haven't been
able to reproduce using open source Xen, even when using the same
version as the one reported by EC2. Is there anyway you could provide
some help debugging this? Without seeing the Xen code that causes
VCPUOP_set_singleshot_timer to return EINVAL it is quite hard to figure
out what's happening inside the hypervisor.
Hi Roger,
VCPUOP_set_singleshot_timer returns -EINVAL when:
1) the specified vCPU ID is out of range (0 or MAX_VIRT_CPUS)
2) the specified vCPU ID doesn't match the running vCPU.
It seems that there is a confusion between the logical vCPU ID and the
local APIC physical ID.
I added some debugging to case 2):
diff --git a/xen/common/domain.c b/xen/common/domain.c
index e728819..e3efb8c 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -901,7 +901,12 @@ long do_vcpu_op(int cmd, int vcpuid,
XEN_GUEST_HANDLE(void) arg)
struct vcpu_set_singleshot_timer set;
if ( v != current )
+{
+printk(Domain %d (vcpu#%d) VCPUOP_set_singleshot_timer specified
vcpuid %d\n,
+ d-domain_id, current-vcpu_id, vcpuid);
+
return -EINVAL;
+}
if ( copy_from_guest(set, arg, 1) )
return -EFAULT;
The output from booting ami-e75c358e on a cr1.8xlarge:
(XEN) Domain 1 (vcpu#16) VCPUOP_set_singleshot_timer specified vcpuid 1
(XEN) Domain 1 (vcpu#7) VCPUOP_set_singleshot_timer specified vcpuid 14
(XEN) Domain 1 (vcpu#23) VCPUOP_set_singleshot_timer specified vcpuid 15
(XEN) Domain 1 (vcpu#11) VCPUOP_set_singleshot_timer specified vcpuid 22
(XEN) Domain 1 (vcpu#27) VCPUOP_set_singleshot_timer specified vcpuid 23
(XEN) Domain 1 (vcpu#18) VCPUOP_set_singleshot_timer specified vcpuid 5
(XEN) Domain 1 (vcpu#2) VCPUOP_set_singleshot_timer specified vcpuid 4
(XEN) Domain 1 (vcpu#9) VCPUOP_set_singleshot_timer specified vcpuid 18
(XEN) Domain 1 (vcpu#25) VCPUOP_set_singleshot_timer specified vcpuid 19
(XEN) Domain 1 (vcpu#1) VCPUOP_set_singleshot_timer specified vcpuid 2
(XEN) Domain 1 (vcpu#6) VCPUOP_set_singleshot_timer specified vcpuid 12
(XEN) Domain 1 (vcpu#22) VCPUOP_set_singleshot_timer specified vcpuid 13
(XEN) Domain 1 (vcpu#26) VCPUOP_set_singleshot_timer specified vcpuid 21
(XEN) Domain 1 (vcpu#10) VCPUOP_set_singleshot_timer specified vcpuid 20
(XEN) Domain 1 (vcpu#14) VCPUOP_set_singleshot_timer specified vcpuid 28
(XEN) Domain 1 (vcpu#30) VCPUOP_set_singleshot_timer specified vcpuid 29
(XEN) Domain 1 (vcpu#3) VCPUOP_set_singleshot_timer specified vcpuid 6
(XEN) Domain 1 (vcpu#19) VCPUOP_set_singleshot_timer specified vcpuid 7
(XEN) Domain 1 (vcpu#12) VCPUOP_set_singleshot_timer specified vcpuid 24
(XEN) Domain 1 (vcpu#28) VCPUOP_set_singleshot_timer specified vcpuid 25
(XEN) Domain 1 (vcpu#5) VCPUOP_set_singleshot_timer specified vcpuid 10
(XEN) Domain 1 (vcpu#21) VCPUOP_set_singleshot_timer specified vcpuid 11
(XEN) Domain 1 (vcpu#24) VCPUOP_set_singleshot_timer specified vcpuid 17
(XEN) Domain 1 (vcpu#8) VCPUOP_set_singleshot_timer specified vcpuid 16
(XEN) Domain 1 (vcpu#17) VCPUOP_set_singleshot_timer specified vcpuid 3
(XEN) Domain 1 (vcpu#20) VCPUOP_set_singleshot_timer specified vcpuid 9
(XEN) Domain 1 (vcpu#4) VCPUOP_set_singleshot_timer specified vcpuid 8
(XEN) Domain 1 (vcpu#13) VCPUOP_set_singleshot_timer specified vcpuid 26
(XEN) Domain 1 (vcpu#29) VCPUOP_set_singleshot_timer specified vcpuid 27
(XEN) Domain 1 (vcpu#15) VCPUOP_set_singleshot_timer specified vcpuid 30
Note from the FreeBSD boot output:
APIC: CPU 0 has ACPI ID 0
APIC: CPU 1 has ACPI ID 16
APIC: CPU 2 has ACPI ID 1
APIC: CPU 3 has ACPI ID 17
APIC: CPU 4 has ACPI ID 2
APIC: CPU 5 has ACPI ID 18
APIC: CPU 6 has ACPI ID 3
APIC: CPU 7 has ACPI ID 19
APIC: CPU 8 has ACPI ID 4
APIC: CPU 9 has ACPI ID 20
APIC: CPU 10 has ACPI ID 5
APIC: CPU 11 has ACPI ID 21
APIC: CPU 12 has ACPI ID 6
APIC: CPU 13 has ACPI ID 22
APIC: CPU 14 has ACPI ID 7
APIC: CPU 15 has ACPI ID 23
APIC: CPU 16 has ACPI ID 8
APIC: CPU 17 has ACPI ID 24
APIC: CPU 18 has ACPI ID 9
APIC: CPU 19 has ACPI ID 25
APIC: CPU 20 has ACPI ID 10
APIC: CPU 21 has ACPI ID 26
APIC: CPU 22 has ACPI ID 11
APIC: CPU 23 has ACPI ID 27
APIC: CPU 24 has ACPI ID 12
APIC: CPU 25 has ACPI ID 28
APIC: CPU 26 has ACPI ID 13
APIC: CPU 27 has ACPI ID 29
APIC: CPU 28 has ACPI ID 14
APIC: CPU 29 has ACPI ID 30
APIC: CPU 30 has ACPI ID 15
APIC: CPU 31 has ACPI ID 31
--msw
___
Re: FreeBSD PVHVM call for testing
Hi, I've just successfully run FreeBSD 9.1 based guest with 'pvhvm_v8' based kernel under Xen 4.2.2. So I couldn't confirm any issue with the kernel both on Xen 3.4.4 and 4.2.2. Nice Job. Hypervisor details: # xm info host : release: 3.8.7-1.el6xen version: #1 SMP Tue Apr 16 13:14:14 EEST 2013 machine: x86_64 nr_cpus: 4 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 1995 hw_caps: bfebfbff:28100800::3b40:009ce3bd::0001: virt_caps : hvm total_memory : 16374 free_memory: 7194 free_cpus : 0 xen_major : 4 xen_minor : 2 xen_extra : .2 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : unavailable xen_commandline: dom0_mem=409600 cc_compiler: gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3) cc_compile_by : mockbuild cc_compile_domain : cc_compile_date: Tue May 7 19:26:49 EST 2013 xend_config_format : 4 DomU details: # xm list --long f2tbrxodmgk9ng (domain (domid 146) (cpu_weight 400) (cpu_cap 0) (pool_name Pool-0) (bootloader '') (vcpus 4) (cpus (() () () ())) (on_poweroff destroy) (description '') (on_crash restart) (uuid 355cfb26-4793-f85a-e330-7b6bfcae49b5) (bootloader_args '') (name f2tbrxodmgk9ng) (on_reboot restart) (maxmem 1024) (memory 1024) (shadow_memory 12) (features '') (on_xend_start ignore) (on_xend_stop ignore) (start_time 1369384081.34) (cpu_time 59.956655605) (online_vcpus 4) (image (hvm (kernel '') (superpages 0) (videoram 4) (hpet 0) (stdvga 0) (loader /usr/lib/xen/boot/hvmloader) (xen_platform_pci 1) (nestedhvm 0) (rtc_timeoffset 10801) (pci ()) (hap 1) (localtime 0) (timer_mode 1) (pci_msitranslate 1) (oos 1) (apic 1) (usbdevice tablet) (vpt_align 1) (vncunused 1) (boot cd) (pae 1) (viridian 0) (acpi 1) (vnc 1) (nographic 0) (nomigrate 0) (usb 0) (tsc_mode 0) (guest_os_type default) (device_model /usr/lib64/xen/bin/qemu-dm) (pci_power_mgmt 0) (xauthority /root/.Xauthority) (isa 0) (notes (SUSPEND_CANCEL 1)) ) ) (status 2) (state -b) (store_mfn 1044476) (device (vif (bridge nnl9l2z5l3q3d8) (uuid daeabd68-05a0-f25b-ba65-394627505b50) (script /etc/xen/scripts/vif-bridge) (ip 109.123.91.166) (mac 00:16:3e:e8:88:49) (vifname qgdvmt5h6d2l9s) (backend 0) ) ) (device (console (protocol vt100) (location 7) (uuid c670a71d-4c3b-1fcb-974a-587f17740a6c) ) ) (device (vbd (protocol x86_64-abi) (uuid 9067929c-9b48-99c6-5526-e771d43f427c) (bootable 1) (dev hda:disk) (uname phy:/dev/fv4zl7t2h5wbeq/o76ciuubu0r986) (mode w) (backend 0) (VDI '') ) ) (device (vbd (protocol x86_64-abi) (uuid 2ae3630e-0e8e-04e4-8caf-ac4d1e9fd402) (bootable 0) (dev hdb:disk) (uname phy:/dev/fv4zl7t2h5wbeq/xi0nw7u4zo0bu9) (mode w) (backend 0) (VDI '') ) ) (device (vbd (protocol x86_64-abi) (uuid 33d3e25c-0c1c-ced6-c8b6-5a706ab0d403) (bootable 0) (dev hdc:cdrom) (uname file:/tools/freebsd/boot-freebsd-generic.iso) (mode r) (backend 0) (VDI '') ) ) (device (vfb (vncunused 1) (vnc 1) (uuid 438a2ffd-bec7-1e54-bb0b-4fdd400517cf) (location 0.0.0.0:5908) ) ) ) DomU from inside: # uname -a FreeBSD yurak2.vm 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+03cdadc: Thu May 23 18:55:33 AST 2013 r...@yurak2.vm:/usr/obj/freebsd/sys/XENHVM amd64 --- Yura On May 22, 2013, at 18:27 PM, Yuriy Kohut yko...@onapp.com wrote: Hi, I've just successfully run FreeBSD 9.1 based guest with 'pvhvm_v8' based kernel under Xen 3.4.4. Hypervisor details: # xm info host : *** release
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Thu, May 23, 2013 at 07:41:50PM +0200, Roger Pau Monné wrote: 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: I feel a bit stupid to ask this, but how I install 'gmake'? Doing 'pkg_add -r gmake' tells me there is no package (perhaps I am using a too modern version of FreeBSD (FreeBSD-10.0-CURRENT-amd64-20130512-r250582-release.iso)? The Wiki mentions how to install git but that fails b/c it can't find gmake. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Fri, May 24, 2013 at 10:14 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Thu, May 23, 2013 at 07:41:50PM +0200, Roger Pau Monné wrote: 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: I feel a bit stupid to ask this, but how I install 'gmake'? Doing 'pkg_add -r gmake' tells me there is no package (perhaps I am using a too modern version of FreeBSD (FreeBSD-10.0-CURRENT-amd64-20130512-r250582-release.iso)? The Wiki mentions how to install git but that fails b/c it can't find gmake. on 10-CURRENT you need to use pkg or build from ports/devel/gmake ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On 24/05/13 16:14, Konrad Rzeszutek Wilk wrote: On Thu, May 23, 2013 at 07:41:50PM +0200, Roger Pau Monné wrote: 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: I feel a bit stupid to ask this, but how I install 'gmake'? Doing 'pkg_add -r gmake' tells me there is no package (perhaps I am using a too modern version of FreeBSD (FreeBSD-10.0-CURRENT-amd64-20130512-r250582-release.iso)? The Wiki mentions how to install git but that fails b/c it can't find gmake. Did you install the ports tree during the installation? If so I've always successfully installed git using: # whereis git # cd output of above command # make install Maybe the ISO you picked as a broken ports snapshot? ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Thu, May 23, 2013 at 6:30 AM, Roger Pau Monné roger@citrix.comwrote: On 23/05/13 15:20, Jeroen van der Ham wrote: On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM You mention on that page that it is easier to install on 10.0-CURRENT snapshots. What are the issues with installing this on 9.1? Is it possible? I don't think it is recommended to use a HEAD (10) kernel with a 9.1 userland. You can always install a 9.1 and then do a full update with the source on my repository. Actually in FreeBSD, it is possible to run an older userland on a newer kernel, and a lot of effort is spent in preserving this type of backwards compatibility. So a 9.1 userland with a 10 kernel will work. However, running a newer userland on an older kernel is not guaranteed to work. So running a 10 userland with a 9.1 kernel will most likely not work. However, since you guys are doing very cutting edge stuff with 10-CURRENT, it is better that you do not waste time with 9.1. I recommend you start with a 10.0 CURRENT snapshot ISO and go from there. I am going through a similar setup exercise with a Google Summer of Code student where he needs to have a latest CURRENT system running in a VM. I wrote this blog post: http://blogs.freebsdish.org/rodrigc/2013/05/24/setting-up-a-vm-for-doing-gsoc-work/ for the steps how to do it. You can follow those steps to get bootstrapped with a working environment if it helps you out. Good luck. -- Craig ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 22/05/13 22:03, Colin Percival wrote: On 05/22/13 04:45, Roger Pau Monné wrote: On 18/05/13 17:44, Colin Percival wrote: That seems to work. dmesg is attached. Are there any particular tests you'd like me to run? I have not tested ZFS, that might be a good one. If you are running this on Xen 3.4 the behaviour should be the same as without this patches, so there shouldn't be many differences. I don't use ZFS personally, so I'm not sure exactly what tests to run on it; hopefully someone else can take care of that. If you could try that on Xen 4.0 at least (if I remember correctly that's when the vector callback was introduced), you should see the PV timer getting attached, and a performance increase. Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with a panic -- console output below. I can get a backtrace and possibly even a dump if those would help. Hello Colin, Thanks for the test, I've been using Xen 4.2 (and 4.3) without problems so far. By looking at the Xen code, the only reason the timer setup could return -22 (EINVAL), is that we try to set the timer for a different vCPU than the one we are running on. I've been able to boot a 32 vCPU DomU on my 8way box using Xen 4.2.1 (using both qemu-xen and qemu-xen-traditional device models), so I'm unsure if this could be due to some patch Amazon applies to Xen. Could you try the following patch and post the error message? I would like to see if the cpuid reported by kdb and the vCPU that we are trying to set the timer are the same. Booting... GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #68: Wed May 22 19:00:14 CEST 2013 root@:/usr/obj/usr/src/sys/XENHVM amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. XEN: Hypervisor version 4.2 detected. CPU: Intel(R) Xeon(R) CPU W3550 @ 3.07GHz (3066.83-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Family = 0x6 Model = 0x1a Stepping = 5 Features=0x1783fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT Features2=0x81b82201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,HV AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF real memory = 4286578688 (4088 MB) avail memory = 3961323520 (3777 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM FreeBSD/SMP: Multiprocessor System Detected: 32 CPUs FreeBSD/SMP: 2 package(s) x 16 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 cpu4 (AP): APIC ID: 8 cpu5 (AP): APIC ID: 10 cpu6 (AP): APIC ID: 12 cpu7 (AP): APIC ID: 14 cpu8 (AP): APIC ID: 16 cpu9 (AP): APIC ID: 18 cpu10 (AP): APIC ID: 20 cpu11 (AP): APIC ID: 22 cpu12 (AP): APIC ID: 24 cpu13 (AP): APIC ID: 26 cpu14 (AP): APIC ID: 28 cpu15 (AP): APIC ID: 30 cpu16 (AP): APIC ID: 32 cpu17 (AP): APIC ID: 34 cpu18 (AP): APIC ID: 36 cpu19 (AP): APIC ID: 38 cpu20 (AP): APIC ID: 40 cpu21 (AP): APIC ID: 42 cpu22 (AP): APIC ID: 44 cpu23 (AP): APIC ID: 46 cpu24 (AP): APIC ID: 48 cpu25 (AP): APIC ID: 50 cpu26 (AP): APIC ID: 52 cpu27 (AP): APIC ID: 54 cpu28 (AP): APIC ID: 56 cpu29 (AP): APIC ID: 58 cpu30 (AP): APIC ID: 60 cpu31 (AP): APIC ID: 62 random device not loaded; using insecure entropy ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-47 on motherboard kbd1 at kbdmux0 xen_et0: Xen PV Clock on motherboard Event timer XENTIMER frequency 10 Hz quality 950 Timecounter XENTIMER frequency 10 Hz quality 950 acpi0: Xen on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 cpu4: ACPI CPU on acpi0 cpu5: ACPI CPU on acpi0 cpu6: ACPI CPU on acpi0 cpu7: ACPI CPU on acpi0 cpu8: ACPI CPU on acpi0 cpu9: ACPI CPU on acpi0 cpu10: ACPI CPU on acpi0 cpu11: ACPI CPU on acpi0 cpu12: ACPI CPU on acpi0 cpu13: ACPI CPU on acpi0 cpu14: ACPI CPU on acpi0 cpu15: ACPI CPU on acpi0 cpu16: ACPI CPU on acpi0 cpu17: ACPI CPU on acpi0 cpu18: ACPI CPU on acpi0 cpu19: ACPI CPU on acpi0 cpu20: ACPI CPU on acpi0 cpu21: ACPI CPU on acpi0 cpu22: ACPI CPU on acpi0 cpu23: ACPI CPU on acpi0 cpu24: ACPI CPU on acpi0 cpu25: ACPI CPU on acpi0 cpu26: ACPI CPU on acpi0 cpu27: ACPI CPU on acpi0 cpu28: ACPI CPU on acpi0 cpu29: ACPI CPU on acpi0 cpu30: ACPI CPU on acpi0 cpu31: ACPI CPU on acpi0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 6250 Hz quality 950 attimer0: AT
Re: FreeBSD PVHVM call for testing
On Thu, May 23, 2013 at 8:57 AM, Jeroen van der Ham jer...@dckd.nl wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. Curious if this would work under XEN XCP (Xen Cloud Platform) [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 23/05/13 15:20, Jeroen van der Ham wrote: On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM You mention on that page that it is easier to install on 10.0-CURRENT snapshots. What are the issues with installing this on 9.1? Is it possible? I don't think it is recommended to use a HEAD (10) kernel with a 9.1 userland. You can always install a 9.1 and then do a full update with the source on my repository. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné roger@citrix.comwrote: On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. curious as the from what rev you guys forked your XENPVM work from HEAD, so i can assure Ive not lost some fixes, new commits from upstream This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné roger@citrix.comwrote: On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 I built the rev_9 branch on a XCP host and rebooted, however I am seeing on boot after ugen0.2: QEMU 0.10.2 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 10 ] Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip) db ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 23 May 2013 20:30, Outback Dingo outbackdi...@gmail.com wrote: On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné roger@citrix.comwrote: On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 I built the rev_9 branch on a XCP host and rebooted, however I am seeing on boot after ugen0.2: QEMU 0.10.2 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 10 ] Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip) db 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. -- wbr, pluknet ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 23/05/13 18:30, Outback Dingo wrote: On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 I built the rev_9 branch on a XCP host and rebooted, however I am seeing on boot after ugen0.2: QEMU 0.10.2 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 10 ] Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip) db 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? ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Thu, May 23, 2013 at 12:48 PM, Roger Pau Monné roger@citrix.comwrote: On 23/05/13 18:30, Outback Dingo wrote: On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 I built the rev_9 branch on a XCP host and rebooted, however I am seeing on boot after ugen0.2: QEMU 0.10.2 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 10 ] Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip) db 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? great how does one go about disabling the cdrom, i get some disk parameters needs to be removed from the vm template before boot ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
Hi, Just remove this line (or pointing to a similar file from the template: (It's part of the disks definition: 'file:/root/freebsd-10.iso,hdc:cdrom,r', Jeroen. On 23 May 2013, at 19:02, Outback Dingo outbackdi...@gmail.com wrote: On Thu, May 23, 2013 at 12:48 PM, Roger Pau Monné roger@citrix.comwrote: On 23/05/13 18:30, Outback Dingo wrote: On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 I built the rev_9 branch on a XCP host and rebooted, however I am seeing on boot after ugen0.2: QEMU 0.10.2 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 10 ] Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip) db 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? great how does one go about disabling the cdrom, i get some disk parameters needs to be removed from the vm template before boot ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On Thu, May 23, 2013 at 1:22 PM, Jeroen van der Ham jer...@dckd.nl wrote: Hi, Just remove this line (or pointing to a similar file from the template: (It's part of the disks definition: 'file:/root/freebsd-10.iso,hdc:cdrom,r', Thanks, but this is XCP not a generic XEN server where there are vm config files under /etc/xen/ in XCP they dont exists Jeroen. On 23 May 2013, at 19:02, Outback Dingo outbackdi...@gmail.com wrote: On Thu, May 23, 2013 at 12:48 PM, Roger Pau Monné roger@citrix.com wrote: On 23/05/13 18:30, Outback Dingo wrote: On Thu, May 23, 2013 at 9:33 AM, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: On 23/05/13 14:57, Jeroen van der Ham wrote: Hi, On 13 May 2013, at 20:32, Roger Pau Monné roger@citrix.com mailto:roger@citrix.com wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. I've just been able to install it on a VPS using the latest pvhvm_v9 branch. The branch pvhvm_v9 contains an initial implementation of PV IPIs for amd64. I've now finished it and I'm going to port it to i386 also, and push a new branch to the repository. This is good news, because the system I had before actually had trouble with the HVM kernel from 9.1 [0]. I'm going to leave this running for a while and do some more tests on it. Jeroen. [0]: http://www.freebsd.org/cgi/query-pr.cgi?pr=175822 I built the rev_9 branch on a XCP host and rebooted, however I am seeing on boot after ugen0.2: QEMU 0.10.2 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 10 ] Stropped at kdb_enter +0x3b: movq $0,0xad6522(%rip) db 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? great how does one go about disabling the cdrom, i get some disk parameters needs to be removed from the vm template before boot ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
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 g...@freebsd.org Date: Thu May 23 12:24:46 2013 + 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 z...@semihalf.com Sponsored by: The FreeBSD Foundation, Semihalf Thanks for the testing, Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On 21/05/13 19:40, Konrad Rzeszutek Wilk wrote: On Mon, May 13, 2013 at 08:32:56PM +0200, Roger Pau Monné wrote: Hello, Recently Justin T Gibbs, Will Andrews and myself have been working on improving the Xen support in FreeBSD. The main goal of this was to bring full PVHVM support to FreeBSD, right now FreeBSD is only using PV interfaces for disk and network interfaces when running as a HVM guest. The main benefits of this changes are that Xen virtual interrupts (event channels) are now delivered to the guest using a vector callback injection, that is a per-cpu mechanism that allows each vCPU to have different interrupts assigned, so for example network and disk interrupts are delivered to different vCPUs in order to improve performance. With this changes FreeBSD also uses PV timers when running as an HVM guest, which should provide better time keeping and reduce the virtualization overhead, since emulated timers are no longer used. PV IPIs can also be used inside a HVM guest, but this will be implemented later. Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. The code is available in the following git repository, under the branch pvhvm_v5: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM I tried on my Linux box to do this: HEAD is now at 9b25356... xen-netfront: fix detach of network interfaces konrad@phenom:~/git/freebsd$ make kernel-toolchain make buildkernel KERNCONF=XENHVM make installkernel KERNCONF=XENHVM Makefile:123: *** missing separator. Stop. As I thought it would compile the same way you can compile NetBSD - that is even on non-BSD distros. Is that not the case? Should I only do this under a FreeBSD guest? I have never tried to run the FreeBSD build system under something different than FreeBSD, also keep in mind that installkernel will place a bunch of FreeBSD files on your Linux box if you manage to run it. The error itself can probably be fixed by installing and using BSD make (bmake), but anyway you need a FreeBSD HVM DomU in order to test the kernel, so why not do the compilation on it? ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 18/05/13 17:44, Colin Percival wrote: On 05/18/13 02:50, Roger Pau Monné wrote: On 17/05/13 05:07, Colin Percival wrote: On 05/16/13 17:43, Roger Pau Monné wrote: Thanks for testing this on EC2, could you post the full dmesg? So I can see the hypervisor version and if the PV timer is loaded or not. Here's what I get on a cc2.8xlarge with boot_verbose=YES: I've pushed a new branch to my repository, pvhvm_v7 that should work, there was a bug with PCI event channel interrupt set up. I've tested with 3.4 and seems OK, but of course it doesn't support the vector callback injection. That seems to work. dmesg is attached. Are there any particular tests you'd like me to run? I have not tested ZFS, that might be a good one. If you are running this on Xen 3.4 the behaviour should be the same as without this patches, so there shouldn't be many differences. If you could try that on Xen 4.0 at least (if I remember correctly that's when the vector callback was introduced), you should see the PV timer getting attached, and a performance increase. If anyone else wants to play with this, you can launch ami-e75c358e in the EC2 us-east-1 region. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Wed, May 22, 2013 at 01:41:02PM +0200, Roger Pau Monné wrote: On 21/05/13 19:40, Konrad Rzeszutek Wilk wrote: On Mon, May 13, 2013 at 08:32:56PM +0200, Roger Pau Monné wrote: Hello, Recently Justin T Gibbs, Will Andrews and myself have been working on improving the Xen support in FreeBSD. The main goal of this was to bring full PVHVM support to FreeBSD, right now FreeBSD is only using PV interfaces for disk and network interfaces when running as a HVM guest. The main benefits of this changes are that Xen virtual interrupts (event channels) are now delivered to the guest using a vector callback injection, that is a per-cpu mechanism that allows each vCPU to have different interrupts assigned, so for example network and disk interrupts are delivered to different vCPUs in order to improve performance. With this changes FreeBSD also uses PV timers when running as an HVM guest, which should provide better time keeping and reduce the virtualization overhead, since emulated timers are no longer used. PV IPIs can also be used inside a HVM guest, but this will be implemented later. Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. The code is available in the following git repository, under the branch pvhvm_v5: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM I tried on my Linux box to do this: HEAD is now at 9b25356... xen-netfront: fix detach of network interfaces konrad@phenom:~/git/freebsd$ make kernel-toolchain make buildkernel KERNCONF=XENHVM make installkernel KERNCONF=XENHVM Makefile:123: *** missing separator. Stop. As I thought it would compile the same way you can compile NetBSD - that is even on non-BSD distros. Is that not the case? Should I only do this under a FreeBSD guest? I have never tried to run the FreeBSD build system under something different than FreeBSD, also keep in mind that installkernel will place a bunch of FreeBSD files on your Linux box if you manage to run it. The error itself can probably be fixed by installing and using BSD make (bmake), but anyway you need a FreeBSD HVM DomU in order to test the kernel, so why not do the compilation on it? Oh, sure. Just thought that the NetBSD method (which also allows one to build the kernel and the iso) was the same on FreeBSd. Will of course install first the HVM domU and do it again. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 05/22/13 04:45, Roger Pau Monné wrote: On 18/05/13 17:44, Colin Percival wrote: That seems to work. dmesg is attached. Are there any particular tests you'd like me to run? I have not tested ZFS, that might be a good one. If you are running this on Xen 3.4 the behaviour should be the same as without this patches, so there shouldn't be many differences. I don't use ZFS personally, so I'm not sure exactly what tests to run on it; hopefully someone else can take care of that. If you could try that on Xen 4.0 at least (if I remember correctly that's when the vector callback was introduced), you should see the PV timer getting attached, and a performance increase. Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with a panic -- console output below. I can get a backtrace and possibly even a dump if those would help. Booting [/boot/kernel/kernel]... -\|/-\|GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009e000 SMAP type=02 base=0009e000 len=2000 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=eff0 SMAP type=02 base=fc00 len=0400 SMAP type=01 base=0001 len=003c1900 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) MADT: Found CPU APIC ID 12 ACPI ID 6: enabled SMP: Added CPU 12 (AP) MADT: Found CPU APIC ID 14 ACPI ID 7: enabled SMP: Added CPU 14 (AP) MADT: Found CPU APIC ID 32 ACPI ID 8: enabled SMP: Added CPU 32 (AP) MADT: Found CPU APIC ID 34 ACPI ID 9: enabled SMP: Added CPU 34 (AP) MADT: Found CPU APIC ID 36 ACPI ID 10: enabled SMP: Added CPU 36 (AP) MADT: Found CPU APIC ID 38 ACPI ID 11: enabled SMP: Added CPU 38 (AP) MADT: Found CPU APIC ID 40 ACPI ID 12: enabled SMP: Added CPU 40 (AP) MADT: Found CPU APIC ID 42 ACPI ID 13: enabled SMP: Added CPU 42 (AP) MADT: Found CPU APIC ID 44 ACPI ID 14: enabled SMP: Added CPU 44 (AP) MADT: Found CPU APIC ID 46 ACPI ID 15: enabled SMP: Added CPU 46 (AP) MADT: Found CPU APIC ID 1 ACPI ID 16: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 17: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 18: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 7 ACPI ID 19: enabled SMP: Added CPU 7 (AP) MADT: Found CPU APIC ID 9 ACPI ID 20: enabled SMP: Added CPU 9 (AP) MADT: Found CPU APIC ID 11 ACPI ID 21: enabled SMP: Added CPU 11 (AP) MADT: Found CPU APIC ID 13 ACPI ID 22: enabled SMP: Added CPU 13 (AP) MADT: Found CPU APIC ID 15 ACPI ID 23: enabled SMP: Added CPU 15 (AP) MADT: Found CPU APIC ID 33 ACPI ID 24: enabled SMP: Added CPU 33 (AP) MADT: Found CPU APIC ID 35 ACPI ID 25: enabled SMP: Added CPU 35 (AP) MADT: Found CPU APIC ID 37 ACPI ID 26: enabled SMP: Added CPU 37 (AP) MADT: Found CPU APIC ID 39 ACPI ID 27: enabled SMP: Added CPU 39 (AP) MADT: Found CPU APIC ID 41 ACPI ID 28: enabled SMP: Added CPU 41 (AP) MADT: Found CPU APIC ID 43 ACPI ID 29: enabled SMP: Added CPU 43 (AP) MADT: Found CPU APIC ID 45 ACPI ID 30: enabled SMP: Added CPU 45 (AP) MADT: Found CPU APIC ID 47 ACPI ID 31: enabled SMP: Added CPU 47 (AP) MADT: Found CPU APIC ID 0 ACPI ID 32: disabled MADT: Found CPU APIC ID 0 ACPI ID 33: disabled MADT: Found CPU APIC ID 0 ACPI ID 34: disabled MADT: Found CPU APIC ID 0 ACPI ID 35: disabled MADT: Found CPU APIC ID 0 ACPI ID 36: disabled MADT: Found CPU APIC ID 0 ACPI ID 37: disabled MADT: Found CPU APIC ID 0 ACPI ID 38: disabled MADT: Found CPU APIC ID 0 ACPI ID 39: disabled MADT: Found CPU APIC ID 0 ACPI ID 40: disabled MADT: Found CPU APIC ID 0 ACPI ID 41: disabled MADT: Found CPU APIC ID 0 ACPI ID 42: disabled MADT: Found CPU APIC ID 0 ACPI ID 43: disabled MADT: Found CPU APIC ID 0 ACPI ID 44: disabled MADT: Found CPU APIC ID 0 ACPI ID 45: disabled MADT: Found CPU APIC ID 0 ACPI ID 46: disabled MADT: Found CPU APIC ID 0 ACPI ID 47: disabled MADT: Found CPU APIC ID 0 ACPI ID 48: disabled MADT: Found CPU APIC ID 0 ACPI ID 49: disabled MADT: Found CPU APIC ID 0 ACPI ID 50: disabled MADT: Found CPU APIC ID 0 ACPI ID 51: disabled MADT: Found CPU APIC ID 0 ACPI ID 52: disabled MADT: Found CPU APIC ID 0 ACPI ID 53: disabled MADT: Found CPU APIC ID 0 ACPI ID 54: disabled MADT: Found CPU APIC ID 0 ACPI ID 55: disabled MADT: Found CPU APIC ID 0 ACPI ID 56: disabled MADT: Found CPU APIC ID 0 ACPI ID 57: disabled MADT: Found CPU APIC ID 0 ACPI ID 58: disabled MADT: Found CPU APIC ID 0 ACPI ID 59: disabled MADT: Found CPU APIC ID 0 ACPI
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Mon, May 13, 2013 at 08:32:56PM +0200, Roger Pau Monné wrote: Hello, Recently Justin T Gibbs, Will Andrews and myself have been working on improving the Xen support in FreeBSD. The main goal of this was to bring full PVHVM support to FreeBSD, right now FreeBSD is only using PV interfaces for disk and network interfaces when running as a HVM guest. The main benefits of this changes are that Xen virtual interrupts (event channels) are now delivered to the guest using a vector callback injection, that is a per-cpu mechanism that allows each vCPU to have different interrupts assigned, so for example network and disk interrupts are delivered to different vCPUs in order to improve performance. With this changes FreeBSD also uses PV timers when running as an HVM guest, which should provide better time keeping and reduce the virtualization overhead, since emulated timers are no longer used. PV IPIs can also be used inside a HVM guest, but this will be implemented later. Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. The code is available in the following git repository, under the branch pvhvm_v5: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM I tried on my Linux box to do this: HEAD is now at 9b25356... xen-netfront: fix detach of network interfaces konrad@phenom:~/git/freebsd$ make kernel-toolchain make buildkernel KERNCONF=XENHVM make installkernel KERNCONF=XENHVM Makefile:123: *** missing separator. Stop. As I thought it would compile the same way you can compile NetBSD - that is even on non-BSD distros. Is that not the case? Should I only do this under a FreeBSD guest? ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 17/05/13 05:07, Colin Percival wrote: On 05/16/13 17:43, Roger Pau Monné wrote: Thanks for testing this on EC2, could you post the full dmesg? So I can see the hypervisor version and if the PV timer is loaded or not. Here's what I get on a cc2.8xlarge with boot_verbose=YES: I've pushed a new branch to my repository, pvhvm_v7 that should work, there was a bug with PCI event channel interrupt set up. I've tested with 3.4 and seems OK, but of course it doesn't support the vector callback injection. Regards, Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 05/18/13 02:50, Roger Pau Monné wrote: On 17/05/13 05:07, Colin Percival wrote: On 05/16/13 17:43, Roger Pau Monné wrote: Thanks for testing this on EC2, could you post the full dmesg? So I can see the hypervisor version and if the PV timer is loaded or not. Here's what I get on a cc2.8xlarge with boot_verbose=YES: I've pushed a new branch to my repository, pvhvm_v7 that should work, there was a bug with PCI event channel interrupt set up. I've tested with 3.4 and seems OK, but of course it doesn't support the vector callback injection. That seems to work. dmesg is attached. Are there any particular tests you'd like me to run? If anyone else wants to play with this, you can launch ami-e75c358e in the EC2 us-east-1 region. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid Table 'FACP' at 0xfc005ee0 Table 'APIC' at 0xfc005fe0 APIC: Found table at 0xfc005fe0 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) MADT: Found CPU APIC ID 12 ACPI ID 6: enabled SMP: Added CPU 12 (AP) MADT: Found CPU APIC ID 14 ACPI ID 7: enabled SMP: Added CPU 14 (AP) MADT: Found CPU APIC ID 32 ACPI ID 8: enabled SMP: Added CPU 32 (AP) MADT: Found CPU APIC ID 34 ACPI ID 9: enabled SMP: Added CPU 34 (AP) MADT: Found CPU APIC ID 36 ACPI ID 10: enabled SMP: Added CPU 36 (AP) MADT: Found CPU APIC ID 38 ACPI ID 11: enabled SMP: Added CPU 38 (AP) MADT: Found CPU APIC ID 40 ACPI ID 12: enabled SMP: Added CPU 40 (AP) MADT: Found CPU APIC ID 42 ACPI ID 13: enabled SMP: Added CPU 42 (AP) MADT: Found CPU APIC ID 44 ACPI ID 14: enabled SMP: Added CPU 44 (AP) MADT: Found CPU APIC ID 46 ACPI ID 15: enabled SMP: Added CPU 46 (AP) MADT: Found CPU APIC ID 1 ACPI ID 16: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 17: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 18: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 7 ACPI ID 19: enabled SMP: Added CPU 7 (AP) MADT: Found CPU APIC ID 9 ACPI ID 20: enabled SMP: Added CPU 9 (AP) MADT: Found CPU APIC ID 11 ACPI ID 21: enabled SMP: Added CPU 11 (AP) MADT: Found CPU APIC ID 13 ACPI ID 22: enabled SMP: Added CPU 13 (AP) MADT: Found CPU APIC ID 15 ACPI ID 23: enabled SMP: Added CPU 15 (AP) MADT: Found CPU APIC ID 33 ACPI ID 24: enabled SMP: Added CPU 33 (AP) MADT: Found CPU APIC ID 35 ACPI ID 25: enabled SMP: Added CPU 35 (AP) MADT: Found CPU APIC ID 37 ACPI ID 26: enabled SMP: Added CPU 37 (AP) MADT: Found CPU APIC ID 39 ACPI ID 27: enabled SMP: Added CPU 39 (AP) MADT: Found CPU APIC ID 41 ACPI ID 28: enabled SMP: Added CPU 41 (AP) MADT: Found CPU APIC ID 43 ACPI ID 29: enabled SMP: Added CPU 43 (AP) MADT: Found CPU APIC ID 45 ACPI ID 30: enabled SMP: Added CPU 45 (AP) MADT: Found CPU APIC ID 47 ACPI ID 31: enabled SMP: Added CPU 47 (AP) Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r+9b25356: Sat May 18 14:46:16 UTC 2013 root@ip-10-140-132-115:/usr/obj/usr/src/sys/XENHVM amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. XEN: Hypervisor version 3.4 detected. XEN: Disabling emulated block and network devices Preloaded elf kernel /boot/kernel/kernel at 0x81912000. Hypervisor: Origin = XenVMMXenVMM Calibrating TSC clock ... TSC clock: 2593802768 Hz CPU: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (2593.80-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206d6 Family = 0x6 Model = 0x2d Stepping = 6 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x9c982201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,XSAVE,OSXSAVE,AVX,HV AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF real memory = 65011712000 (62000 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x01972000 - 0xbfff, 3194544128 bytes (779918 pages) 0x0001 - 0x000efeb95fff, 60108136448 bytes (14674838 pages) avail memory = 60563271680 (57757 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target
Re: FreeBSD PVHVM call for testing
On 05/13/13 11:32, Roger Pau Monné wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. The code is available in the following git repository, under the branch pvhvm_v5: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM I built a XENHVM kernel with this code on EC2, and it hanged after xenbusb_front0: Xen Frontend Devices on xenstore0 With a XENHVM kernel from FreeBSD HEAD the next line after that is xbd0: 10240MB Virtual Block Device at device/vbd/768 on xenbusb_front0 Any ideas? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 16/05/13 19:55, Colin Percival wrote: On 05/13/13 11:32, Roger Pau Monné wrote: Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. The code is available in the following git repository, under the branch pvhvm_v5: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM I built a XENHVM kernel with this code on EC2, and it hanged after xenbusb_front0: Xen Frontend Devices on xenstore0 With a XENHVM kernel from FreeBSD HEAD the next line after that is xbd0: 10240MB Virtual Block Device at device/vbd/768 on xenbusb_front0 Any ideas? Hello Colin, Thanks for testing this on EC2, could you post the full dmesg? So I can see the hypervisor version and if the PV timer is loaded or not. Roger. ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 05/16/13 17:43, Roger Pau Monné wrote: Thanks for testing this on EC2, could you post the full dmesg? So I can see the hypervisor version and if the PV timer is loaded or not. Here's what I get on a cc2.8xlarge with boot_verbose=YES: Booting [/boot/kernel/kernel]... -\|/-\|GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009fc00 SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=bff0 SMAP type=02 base=fc00 len=0400 SMAP type=01 base=0001 len=000e6300 Table 'FACP' at 0xfc005ee0 Table 'APIC' at 0xfc005fe0 APIC: Found table at 0xfc005fe0 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) MADT: Found CPU APIC ID 12 ACPI ID 6: enabled SMP: Added CPU 12 (AP) MADT: Found CPU APIC ID 14 ACPI ID 7: enabled SMP: Added CPU 14 (AP) MADT: Found CPU APIC ID 32 ACPI ID 8: enabled SMP: Added CPU 32 (AP) MADT: Found CPU APIC ID 34 ACPI ID 9: enabled SMP: Added CPU 34 (AP) MADT: Found CPU APIC ID 36 ACPI ID 10: enabled SMP: Added CPU 36 (AP) MADT: Found CPU APIC ID 38 ACPI ID 11: enabled SMP: Added CPU 38 (AP) MADT: Found CPU APIC ID 40 ACPI ID 12: enabled SMP: Added CPU 40 (AP) MADT: Found CPU APIC ID 42 ACPI ID 13: enabled SMP: Added CPU 42 (AP) MADT: Found CPU APIC ID 44 ACPI ID 14: enabled SMP: Added CPU 44 (AP) MADT: Found CPU APIC ID 46 ACPI ID 15: enabled SMP: Added CPU 46 (AP) MADT: Found CPU APIC ID 1 ACPI ID 16: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 17: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 18: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 7 ACPI ID 19: enabled SMP: Added CPU 7 (AP) MADT: Found CPU APIC ID 9 ACPI ID 20: enabled SMP: Added CPU 9 (AP) MADT: Found CPU APIC ID 11 ACPI ID 21: enabled SMP: Added CPU 11 (AP) MADT: Found CPU APIC ID 13 ACPI ID 22: enabled SMP: Added CPU 13 (AP) MADT: Found CPU APIC ID 15 ACPI ID 23: enabled SMP: Added CPU 15 (AP) MADT: Found CPU APIC ID 33 ACPI ID 24: enabled SMP: Added CPU 33 (AP) MADT: Found CPU APIC ID 35 ACPI ID 25: enabled SMP: Added CPU 35 (AP) MADT: Found CPU APIC ID 37 ACPI ID 26: enabled SMP: Added CPU 37 (AP) MADT: Found CPU APIC ID 39 ACPI ID 27: enabled SMP: Added CPU 39 (AP) MADT: Found CPU APIC ID 41 ACPI ID 28: enabled SMP: Added CPU 41 (AP) MADT: Found CPU APIC ID 43 ACPI ID 29: enabled SMP: Added CPU 43 (AP) MADT: Found CPU APIC ID 45 ACPI ID 30: enabled SMP: Added CPU 45 (AP) MADT: Found CPU APIC ID 47 ACPI ID 31: enabled SMP: Added CPU 47 (AP) Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r+7c97e5b: Fri May 17 02:38:29 UTC 2013 root@ip-10-148-212-216:/usr/obj/usr/src/sys/XENHVM amd64 FreeBSD clang version 3.3 (trunk 178860) 20130405 WARNING: WITNESS option enabled, expect reduced performance. XEN: Hypervisor version 3.4 detected. XEN: Disabling emulated block and network devices Preloaded elf kernel /boot/kernel/kernel at 0x81912000. Hypervisor: Origin = XenVMMXenVMM Calibrating TSC clock ... TSC clock: 2593801200 Hz CPU: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (2593.80-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206d7 Family = 0x6 Model = 0x2d Stepping = 7 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x9c982201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,XSAVE,OSXSAVE,AVX,HV AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF real memory = 65011712000 (62000 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x01972000 - 0xbfff, 3194544128 bytes (779918 pages) 0x0001 - 0x000efeb95fff, 60108136448 bytes (14674838 pages) avail memory = 60563271680 (57757 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Mon, May 13, 2013 at 7:32 PM, Roger Pau Monné roger@citrix.com wrote: Hello, Recently Justin T Gibbs, Will Andrews and myself have been working on improving the Xen support in FreeBSD. The main goal of this was to bring full PVHVM support to FreeBSD, right now FreeBSD is only using PV interfaces for disk and network interfaces when running as a HVM guest. The main benefits of this changes are that Xen virtual interrupts (event channels) are now delivered to the guest using a vector callback injection, that is a per-cpu mechanism that allows each vCPU to have different interrupts assigned, so for example network and disk interrupts are delivered to different vCPUs in order to improve performance. With this changes FreeBSD also uses PV timers when running as an HVM guest, which should provide better time keeping and reduce the virtualization overhead, since emulated timers are no longer used. PV IPIs can also be used inside a HVM guest, but this will be implemented later. Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. Is this something we should try to put on the Xen.org blog? -George ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: [Xen-devel] FreeBSD PVHVM call for testing
On mar, 2013-05-14 at 10:19 +0100, George Dunlap wrote: On Mon, May 13, 2013 at 7:32 PM, Roger Pau Monné roger@citrix.com wrote: Hello, Recently Justin T Gibbs, Will Andrews and myself have been working on improving the Xen support in FreeBSD. The main goal of this was to bring full PVHVM support to FreeBSD, right now FreeBSD is only using PV interfaces for disk and network interfaces when running as a HVM guest. [..] Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. Cool! :-) Is this something we should try to put on the Xen.org blog? I think it definitely should... Whoever is up to write a blog post about it, please, get in touch to me. Soon we'll have the new mailing lists and all the stuff, but for now, just drop me a line, and I can put the post in the pipeline. Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part
FreeBSD PVHVM call for testing
Hello, Recently Justin T Gibbs, Will Andrews and myself have been working on improving the Xen support in FreeBSD. The main goal of this was to bring full PVHVM support to FreeBSD, right now FreeBSD is only using PV interfaces for disk and network interfaces when running as a HVM guest. The main benefits of this changes are that Xen virtual interrupts (event channels) are now delivered to the guest using a vector callback injection, that is a per-cpu mechanism that allows each vCPU to have different interrupts assigned, so for example network and disk interrupts are delivered to different vCPUs in order to improve performance. With this changes FreeBSD also uses PV timers when running as an HVM guest, which should provide better time keeping and reduce the virtualization overhead, since emulated timers are no longer used. PV IPIs can also be used inside a HVM guest, but this will be implemented later. Right now the code is in a state where it can be tested by users, so we would like to encourage FreeBSD and Xen users to test it and provide feedback. The code is available in the following git repository, under the branch pvhvm_v5: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary Also, I've created a wiki page that explains how to set up a FreeBSD PVHVM for testing: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 05/13/13 11:52, Michael Sierchio wrote: I think should be encouraged. We're eagerly awaiting the ability to run FreeBSD in AWS in something other than t1.micro or cluster compute instances. Should we keep holding out hope, or will AWS make HVM available for all instance types before this happens? Err... my AMIs run on all EC2 instance types. On some you have to pay the Windows rate, that's all. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
The Windoze tax is unacceptable for a number of reasons - the primary reason is that I'm not running Windows. I don't think the licensing scheme is unfair for those actually running Windows, mind you. At the AWS Summit, an assertion was made that HVM support might be coming soon for all instance types for *NIX OSes. I hope that's true. - M On Mon, May 13, 2013 at 11:59 AM, Colin Percival cperc...@freebsd.orgwrote: On 05/13/13 11:52, Michael Sierchio wrote: I think should be encouraged. We're eagerly awaiting the ability to run FreeBSD in AWS in something other than t1.micro or cluster compute instances. Should we keep holding out hope, or will AWS make HVM available for all instance types before this happens? Err... my AMIs run on all EC2 instance types. On some you have to pay the Windows rate, that's all. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
Re: FreeBSD PVHVM call for testing
On 05/13/13 12:08, Michael Sierchio wrote: The Windoze tax is unacceptable for a number of reasons - the primary reason is that I'm not running Windows. I don't think the licensing scheme is unfair for those actually running Windows, mind you. Right, it's definitely annoying having to pay more -- I just wanted to point out that the ability does exist, if you're willing to pay the price. At the AWS Summit, an assertion was made that HVM support might be coming soon for all instance types for *NIX OSes. I hope that's true. Was it indeed? I must not have been present for that... it certainly would be good news. Certainly all the new instance types they've released in the past few years have had UNIX HVM support. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-virtualization@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization To unsubscribe, send any mail to freebsd-virtualization-unsubscr...@freebsd.org
