Re: Trying to get "a" version of *BSD XEN in .iso to load on a DELL 1850 POWEREDGE (intel chip 64bit)
2012/2/23 Eric Schnoebelen : > > Scott Strobele writes: > - Hi Y'all, > - I am digging through the site, and getting ready to call it a day, I will > - finish reading the entire site tomorrow until I find this, Ian Pratt said > - it was here if it was anywhere. Another Ian named this location as well. > - I just have preferences of stability for a mysql database that will be > - large, and need to scale as far as size of cluster, it should be a lot of > - fun. > - I have used BSD before, and am not finding what I am looking for yet. > > NetBSD has DOM0 and DOMU support in NetBSD 4.*, 5.* and 6.0_BETA. > > I don't know if anyones created a bootable ISO that starts a XEN > hypervisor as part of the boot, but it's been something I've > considered (I've got a couple of boxes that won't boot a generic > kernel, but run fine with a xen hypervisor abstracting the > hardware.) I've done something similar, but with a Linux distribution (Alpine Linux), you can find more info here: http://lists.xen.org/archives/html/xen-devel/2012-01/msg00092.html It's a very minimal Dom0 LiveCD (80MB), that contains a very basic Linux system (uclibc + busybox) plus the necessary tools to run xen. It's quite fast, because it runs from ram. It's still a beta test, but we will probably start releasing this Dom0 LiveCDs with each Alpine Linux release starting from the 1st of April (approximate scheduled release date of the next version). I would also like to do something similar with NetBSD, but that will require some work. Regards, Roger. > -- > Eric Schnoebelen e...@cirr.com http://www.cirr.com > Server (n.), 1. Large, extremely expensive machine that goes "Ping!". > Measuring at least 25 cubic feet, heavy, bulky and giving of more heat > than a nuclear power plant. It's big, it's bad, it's beautiful and > makes it pretty clear what happened to this year's IT-budget. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
XENHVM kernel unable to respond to vnc keyboard
Hello, I've just set up a Xen FreeBSD guest using the XENHVM kernel (release 9.1), and I've found that when using the XENHVM kernel the keyboard input form the vnc client stops working (output to the vnc seems to be ok thought), so I have to set up a serial port before switching to XENHVM or there's no way to interact with the guest (apart from ssh of course). HEAD also seems to be experiencing the same issue. Is this expected/know? I'm using Xen unstable and the device model is Qemu-upstream. Here's the dmesg: Copyright (c) 1992-2012 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 9.1-RELEASE #0: Wed Jan 30 10:39:28 CET 2013 root@:/usr/obj/usr/src/sys/XENHVM amd64 CPU: Intel(R) Xeon(R) CPU X5650 @ 2.67GHz (2660.06-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206c2 Family = 6 Model = 2c Stepping = 2 Features=0x1783fbff Features2=0x83ba2203 AMD Features=0x28100800 AMD Features2=0x1 real memory = 4286578688 (4088 MB) avail memory = 4101226496 (3911 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs FreeBSD/SMP: 1 package(s) x 12 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 ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 6250 Hz quality 950 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: 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 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc200-0xc20f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf000-0xf1ff,0xf302-0xf3020fff at device 2.0 on pci0 xenpci0: port 0xc000-0xc0ff mem 0xf200-0xf2ff irq 28 at device 3.0 on pci0 xenstore0: on xenpci0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: 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: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 qpi0: on motherboard sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fdc0: No FDOUT register! ctl: CAM Target Layer loaded Timecounters tick every 10.000 msec xenbusb_front0: on xenstore0 xenbusb_add_device: Device device/suspend/event-channel ignored. State 6 xn0: at device/vif/0 on xenbusb_front0 xn0: Ethernet address: 00:16:3e:17:2c:00 xenbusb_back0: on xenstore0 xctrl0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xbd0: 20480MB at device/vbd/768 on xenbusb_front0 xbd0: attaching as ad0 cd0 at ata1 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #8 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH] xenbus: fix device detection
On 31/01/13 19:52, Roger Pau Monne wrote: > Devices that cannot be handled should not be closed, instead leave > them as is. This prevents closing the vkbd device, which has the > effect of making Qemu stop sending keys to the guest. > > Tested with qemu-xen-traditional, qemu-xen and qemu stubdomains, all > working as expected. Ping? I've also submitted PR kern/175757 with the patch attached. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: kern/176471: [xen] xn driver crash on detach
The following reply was made to PR kern/176471; it has been noted by GNATS.
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?=
To: ,
Cc:
Subject: Re: kern/176471: [xen] xn driver crash on detach
Date: Thu, 28 Feb 2013 18:00:12 +0100
Hello,
I've been able to reproduce this bug with Xen unstable, here is a fix
for it.
---
From 6206137f80cbe5812294b1733a86f28e5cdc01bd Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Thu, 28 Feb 2013 17:43:34 +0100
Subject: [PATCH] xen-netfront: fix detach of network interfaces
Remove all the media and the interface when detaching it. Prevents the
following panic when detaching an interface (xl network-detach freebsd
1)
xn1: detached
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address = 0xff80028ff2a0
fault code = supervisor read data, page not present
instruction pointer= 0x20:0x809653af
stack pointer = 0x28:0xff8117cb4940
frame pointer = 0x28:0xff8117cb4980
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process= 699 (devd)
[ thread pid 699 tid 100107 ]
Stopped at ifmedia_ioctl+0x3f: movq0x8(%r12),%rcx
db> trace
Tracing pid 706 tid 100059 td 0xfe0006b69480
ifmedia_ioctl() at ifmedia_ioctl+0x3f/frame 0xff80f774c980
ifioctl() at ifioctl+0xeb7/frame 0xff80f774ca40
kern_ioctl() at kern_ioctl+0x1ce/frame 0xff80f774ca90
sys_ioctl() at sys_ioctl+0x11f/frame 0xff80f774cae0
amd64_syscall() at amd64_syscall+0x265/frame 0xff80f774cbf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff80f774cbf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x44c60a, rsp =
0x7fffd678, rbp = 0x7fffd750 ---
PR: 176471
---
sys/dev/xen/netfront/netfront.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/sys/dev/xen/netfront/netfront.c b/sys/dev/xen/netfront/netfront.c
index 88641e3..167fd12 100644
--- a/sys/dev/xen/netfront/netfront.c
+++ b/sys/dev/xen/netfront/netfront.c
@@ -2172,6 +2172,9 @@ static void
netif_free(struct netfront_info *info)
{
netif_disconnect_backend(info);
+ ifmedia_removeall(&info->sc_media);
+ ether_ifdetach(info->xn_ifp);
+ if_free(info->xn_ifp);
#if 0
close_netdev(info);
#endif
--
1.7.7.5 (Apple Git-26)
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: kern/176471: [xen] xn driver crash on detach
The following reply was made to PR kern/176471; it has been noted by GNATS.
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?=
To: ,
Cc:
Subject: Re: kern/176471: [xen] xn driver crash on detach
Date: Thu, 28 Feb 2013 18:58:44 +0100
Hi (again),
I've just realized the previous patch also crashed when trying to
detach an interface that's up and running, the following patch allows
to detach the interface while running without crashing the FreeBSD
kernel.
Also, what do you mean by "changing configuration of xn network"?
---
From 9c0097ed4775c68769049c61e474ddb62cc11d1f Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Thu, 28 Feb 2013 17:43:34 +0100
Subject: [PATCH] xen-netfront: fix detach of network interfaces
Remove all the media and the interface when detaching it. Prevents the
following panic when detaching an interface (xl network-detach freebsd
1)
xn1: detached
Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address = 0xff80028ff2a0
fault code = supervisor read data, page not present
instruction pointer= 0x20:0x809653af
stack pointer = 0x28:0xff8117cb4940
frame pointer = 0x28:0xff8117cb4980
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process= 699 (devd)
[ thread pid 699 tid 100107 ]
Stopped at ifmedia_ioctl+0x3f: movq0x8(%r12),%rcx
db> trace
Tracing pid 706 tid 100059 td 0xfe0006b69480
ifmedia_ioctl() at ifmedia_ioctl+0x3f/frame 0xff80f774c980
ifioctl() at ifioctl+0xeb7/frame 0xff80f774ca40
kern_ioctl() at kern_ioctl+0x1ce/frame 0xff80f774ca90
sys_ioctl() at sys_ioctl+0x11f/frame 0xff80f774cae0
amd64_syscall() at amd64_syscall+0x265/frame 0xff80f774cbf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff80f774cbf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x44c60a, rsp =
0x7fffd678, rbp = 0x7fffd750 ---
PR: 176471
---
sys/dev/xen/netfront/netfront.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/sys/dev/xen/netfront/netfront.c b/sys/dev/xen/netfront/netfront.c
index 88641e3..3a8b8ea 100644
--- a/sys/dev/xen/netfront/netfront.c
+++ b/sys/dev/xen/netfront/netfront.c
@@ -2171,7 +2171,14 @@ netfront_detach(device_t dev)
static void
netif_free(struct netfront_info *info)
{
+ XN_LOCK(info);
+ xn_stop(info);
+ XN_UNLOCK(info);
+ callout_drain(&info->xn_stat_ch);
netif_disconnect_backend(info);
+ ifmedia_removeall(&info->sc_media);
+ ether_ifdetach(info->xn_ifp);
+ if_free(info->xn_ifp);
#if 0
close_netdev(info);
#endif
--
1.7.7.5 (Apple Git-26)
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: misc. questions
On 07/03/13 05:38, Jay West wrote: > Mark wrote... >> You're having success with Xenserver 6.1? That's good news. I wonder why > XCP 1.6 is unable to boot FreeBSD if there's an emulated DVDROM? :( > > Yes. Stock install 64bit 9.1-R as HVM, recompile kernel using supplied > XENHVM config file. Then there's a few things to tweak before rebooting, one > is fstab because of the different naming convention for disk devices or you > choke on reboot after install (you can still do it after by entering correct > device in boot string). The other is the cd drive, you have to remove the cd > device (see http://support.citrix.com/article/CTX132411). There may be > another step I'm forgetting, but that's the basic gist. Oh, and fix rc.conf > to use the xen (xn0) network device. We are still having one really nagging > issue - timekeeping. The clocks are way off and fluctuate wildly. FreeBSD is > selecting the clock source (from several possibilities) that already has the > highest stability rating, so I haven't tried setting the sysctl to use a > different clock source. I see no way to fix this and it's pretty crippling > in my environment anyways. Anyone have a fix for that? I think there were several fixes for the RTC clock recently, so trying the Xen 4.2 branch might bring some improvements. Also, it is possible to use the PV clock from HVM (PVHVM) domains, which will probably bring better stability. I'm going to look into this when I have some spare cycles. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: misc. questions
On 07/03/13 15:00, Jay West wrote: > It was written >> I think there were several fixes for the RTC clock recently, so trying the > Xen 4.2 branch might bring some improvements. > I'm using Citrix Xenserver 6.1, so stuff from the Xen 4.2 branch isn't > available for me Just tried under Xen 4.3 (-unstable), and the problem is fixed, the clock seems to be stable and not drifting any more. I don't know if the patches that fixed that problem have been pulled to either 4.1 or 4.2. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Difference in event channel implementation for Xen PV vs HVM guests
Hello, While working on improving XENHVM (I've been looking at adding PV timers), I've realized that the event channel implementation in PV vs HVM mode differs greatly. Xen PV port uses sys/xen/evtchn/evtchn.c while Xen HVM uses sys/dev/xenpci/evtchn.c, and the Xen HVM implementation is greatly reduced (only contains the necessary functions to operate backends/frontends). To implement PV timers I need to expand the event channel interface for XENHVM, and I was wondering why FreeBSD choose to have two different implementations, the main difference between PV and HVM is the event callback, but I guess this can be abstracted between the two different implementations, and then everything else could be reused. Am I missing something obvious? Is there any known technical problem in modifying XENHVM to use the full event channel implementation present in sys/xen/evtchn/evtchn.c that prevented XENHVM from using it in the first place? (Sorry if I've Cc'ed someone not related) Thanks, Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Difference in event channel implementation for Xen PV vs HVM guests
On 18/03/13 14:08, Justin T. Gibbs wrote: > On Mar 18, 2013, at 6:35 AM, Roger Pau Monné wrote: > >> Hello, >> >> While working on improving XENHVM (I've been looking at adding PV >> timers), I've realized that the event channel implementation in PV vs >> HVM mode differs greatly. Xen PV port uses sys/xen/evtchn/evtchn.c while >> Xen HVM uses sys/dev/xenpci/evtchn.c, and the Xen HVM implementation is >> greatly reduced (only contains the necessary functions to operate >> backends/frontends). >> >> To implement PV timers I need to expand the event channel interface for >> XENHVM, and I was wondering why FreeBSD choose to have two different >> implementations, the main difference between PV and HVM is the event >> callback, but I guess this can be abstracted between the two different >> implementations, and then everything else could be reused. Am I missing >> something obvious? >> >> Is there any known technical problem in modifying XENHVM to use the full >> event channel implementation present in sys/xen/evtchn/evtchn.c that >> prevented XENHVM from using it in the first place? >> >> (Sorry if I've Cc'ed someone not related) >> >> Thanks, Roger. >> ___ >> freebsd-virtualizat...@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to >> "freebsd-virtualization-unsubscr...@freebsd.org" > > Hi Roger, Hello Justin, > > I know of no reasons why XENHVM cannot use the full event channel > interface. In fact, Spectra Logic implemented PV timers and a > general cleanup of the HVM event channel interface. I haven't merged > it back yet because I know the changes break PV and I haven't found > time to clean up the PV code, merge the HVM and PV event channel > systems, and move IPI/MSI delivery to event channels. That sounds great, then FreeBSD will have a fully working PVHVM port. > I've uploaded Spectra's changes here: > > http://people.freebsd.org/~gibbs/xen_ev/ > > The diffs file provides the history of the original checkins to our > Perforce repository. The tar file includes all the files that have > been modified and reflects our efforts to keep our code base in > sync with stable/9. Apart from the PV issues outlined above, I > would expect the code provided to just drop right in to stable/9. Wow, this is a lot of work to keep in a closet, I will start by rebasing those on top of HEAD, and probably try to split them into smaller commits that make logical sense. > > Unfortunately, Xen support is not a current priority for Spectra > so I don't have a lot of day job time to focus on getting this code back > into FreeBSD. However, if this code looks like it would suite > your needs, and you have resources for testing i386/PV, I'd be happy > to collaborate with you and will make the time to help get this > committed. Definitely, you guys did already a lot of work, and it will a shame to lose it, right now I got my plate quite full, but I expect to get on with this in a couple of weeks. Thanks, Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Difference in event channel implementation for Xen PV vs HVM guests
On 18/03/13 14:08, Justin T. Gibbs wrote: > Hi Roger, > > I know of no reasons why XENHVM cannot use the full event channel > interface. In fact, Spectra Logic implemented PV timers and a > general cleanup of the HVM event channel interface. I haven't merged > it back yet because I know the changes break PV and I haven't found > time to clean up the PV code, merge the HVM and PV event channel > systems, and move IPI/MSI delivery to event channels. > > I've uploaded Spectra's changes here: > > http://people.freebsd.org/~gibbs/xen_ev/ Hi Justin, There's at least one file which seems to be missing: sys/x86/xen/hvm.c Could you check if you have that file around? Thanks, Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Difference in event channel implementation for Xen PV vs HVM guests
On 21/03/13 13:43, Roger Pau Monné wrote: > On 18/03/13 14:08, Justin T. Gibbs wrote: > > Hi Roger, >> >> I know of no reasons why XENHVM cannot use the full event channel >> interface. In fact, Spectra Logic implemented PV timers and a >> general cleanup of the HVM event channel interface. I haven't merged >> it back yet because I know the changes break PV and I haven't found >> time to clean up the PV code, merge the HVM and PV event channel >> systems, and move IPI/MSI delivery to event channels. >> >> I've uploaded Spectra's changes here: >> >> http://people.freebsd.org/~gibbs/xen_ev/ > > Hi Justin, > > There's at least one file which seems to be missing: Ops, there at least two files missing: sys/x86/xen/hvm.c sys/xen/evtchn/evtchnvar.h ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU
On 21/02/13 10:18, tech mailinglists wrote: > Hello all, > > I have created a FreeBSD PV DomU image formatted with ZFS. I compiled > FreeBSD with KERNCONF=XEN for the kernel and the normal world and > distribution target. Then I transfered it to a Debian Dom0 with Xen 4.2.1. > > I tried to boot the image befor I migrate it to LVM and I now get teh > following output: > > Parsing config from freebsd-test.cfg > libxl: error: libxl_dm.c:1212:device_model_spawn_outcome: domain 12 > device model: spawn failed (rc=-3) > libxl: error: libxl_qmp.c:641:libxl__qmp_initialize: Connection error: > No such file or directory > Daemon running with PID 3451 > WARNING: loader(8) metadata is missing! > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > APIC: Using the MPTable enumerator. > SMP: Added CPU 0 (BSP) > Copyright (c) 1992-2012 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 9.1-RELEASE #0: Wed Feb 20 14:16:03 CET 2013 > root@build:/usr/obj/usr/src/sys/XEN i386 > WARNING: WITNESS option enabled, expect reduced performance. > Xen reported: 3341.754 MHz processor. > Timecounter "ixen" frequency 1953125 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 975 @ 3.33GHz (3341.75-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0x106a5 Family = 6 Model = 1a > Stepping = 5 > > Features=0xbfe3fbff > > Features2=0x98e3bd > AMD Features=0x2810 > AMD Features2=0x1 > > Data TLB: 4 KB pages, 4-way set associative, 64 entries > 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size > L2 cache: 256 kbytes, 8-way associative, 64 bytes/line > real memory = 2147483648 (2048 MB) > Physical memory chunk(s): > 0x00a58000 - 0x7d995fff, 2096357376 bytes (511806 pages) > avail memory = 2092105728 (1995 MB) > INTR: Adding local APIC 0 as a target > ULE: setup cpu 0 > [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) > [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) > Event-channel device installed. > io: > random: > mem: > Pentium Pro MTRR support enabled > null: > nfslock: pseudo-device > [XEN] xen_rtc_probe: probing Hypervisor RTC clock > rtc0: on motherboard > [XEN] xen_rtc_attach: attaching Hypervisor RTC clock > rtc0: registered as a time-of-day clock (resolution 100us, > adjustment 0.5s) > xenstore0: on motherboard > Grant table initialized > xc0: on motherboard > Device configuration finished. > procfs registered > Event timer "ixen" quality 600 > Timecounters tick every 10.000 msec > lo0: bpf attached > xenbusb_front0: on xenstore0 > xenbusb_add_device: Device device/suspend/event-channel ignored. State 6 > xenbusb_back0: on xenstore0 > xctrl0: on xenstore0 > [XEN] hypervisor wallclock nudged; nudging TOD. > run_interrupt_driven_hooks: still waiting after 60 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 120 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 180 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 240 seconds for > xenbus_free_evtchn > run_interrupt_driven_hooks: still waiting after 300 seconds for > xenbus_free_evtchn > panic: run_interrupt_driven_config_hooks: waited too long > cpuid = 0 > KDB: enter: panic > [ thread pid 0 tid 10 ] > Stopped at kdb_enter+0x3a: movl$0,kdb_why > db> Hello, I've been trying to get a FreeBSD PV guest, I've installed FreeBSD i386 HEAD and then tried to recompile the kernel using KERNCONF=XEN, but Xen refuses to load the resulting kernel: root@loki:~# xl -vvv create -c freebsd32pv.cfg Parsing config from freebsd32pv.cfg libxl: debug: libxl_create.c:1174:do_domain_create: ao 0x22e5a20: create: how=(nil) callback=(nil) poller=0x22e5a80 libxl: debug: libxl_device.c:229:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:265:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_create.c:677:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:327:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x22e60c0: deregister unregistered libxl: debug: libxl_numa.c:435:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=8, nr_vcpus=15, free_memkb=4353 libxl: detail: libxl_dom.c:192:numa_place_domain: NUMA placement candidate with 1 nodes, 8 cpus and 4353 KB free selected domainbuilder: detail: xc_dom_allocate: cmdline="boot_verbose=1,vfs.root.mountfrom=ufs:/dev/ad0s1a,kern.hz=100", features="(null)" libxl: debug: libxl_dom.c:380:libxl__build_pv: pv kernel mapped 0 path /root/kernel.freebsd domainbuilder: detail: xc_dom_ker
Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU
On 26/03/13 10:38, Colin Percival wrote: > On 03/26/13 02:31, Roger Pau Monné wrote: >> Is Xen i386 PV broken? > > Not completely broken, but it's certainly not in a good state. I believe > it's broken with SMP, for example -- if the "crashed on cpu#7" in your > output means cpu#7 from the guest, it would certainly explain things. My guest only has one vcpu (vcpu#0): Domain 12 (vcpu#0) crashed on cpu#7 That is running on physical CPU 7 > HVM is the way to go with FreeBSD/Xen. Yes, I'm already working on that, and got vector callbacks working on both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I was trying to boot a PV guest to see how much breakage this change introduced to PV, but I'm not able to make it work, even without my patches. I've replied to this xen-users thread because the author seem to have a working FreeBSD DomU PV guest, and I was wondering how he did it. From my POV it seems like PV guests hasn't been working for a long time, since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel is detected as non-PAE. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU
On 26/03/13 11:14, Colin Percival wrote: > On 03/26/13 03:10, Roger Pau Monné wrote: >> On 26/03/13 10:38, Colin Percival wrote: >>> On 03/26/13 02:31, Roger Pau Monné wrote: >>>> Is Xen i386 PV broken? >>> >>> Not completely broken, but it's certainly not in a good state. I believe >>> it's broken with SMP, for example -- if the "crashed on cpu#7" in your >>> output means cpu#7 from the guest, it would certainly explain things. >> >> My guest only has one vcpu (vcpu#0): > > Ok, I wasn't sure how to parse that output. > >>> HVM is the way to go with FreeBSD/Xen. >> >> Yes, I'm already working on that, and got vector callbacks working on >> both i386 and amd64 HVM guests, thanks to Justin T. Gibbs patch. Now I >> was trying to boot a PV guest to see how much breakage this change >> introduced to PV, but I'm not able to make it work, even without my patches. >> >> I've replied to this xen-users thread because the author seem to have a >> working FreeBSD DomU PV guest, and I was wondering how he did it. From >> my POV it seems like PV guests hasn't been working for a long time, >> since Xen 3.3 dropped support for non-PAE guests, and the FreeBSD kernel >> is detected as non-PAE. > > I had FreeBSD 8.2-RELEASE and a 9.0-CURRENT @ January 2011 running with PV > in EC2 (http://www.daemonology.net/freebsd-on-ec2/, look for "t1.micro > instances only") and that used PAE. But it's entirely likely that something > got broken in the past two years and nobody noticed because nobody ever uses > PV... I've checked and 9.1 is working OK (at least boots and seems to be functional). I've also found the reason why HEAD doesn't work, and it's probably caused by the switch to clang, which seems to have problems with the ELFNOTE macro, here is a patch that makes i386 PV boot again: --- diff --git a/sys/i386/include/asmacros.h b/sys/i386/include/asmacros.h index c1c3f64..474dfe1 100644 --- a/sys/i386/include/asmacros.h +++ b/sys/i386/include/asmacros.h @@ -211,7 +211,7 @@ #ifdef __STDC__ #define ELFNOTE(name, type, desctype, descdata...) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note; \ .align 4 ; \ .long 2f - 1f /* namesz */; \ .long 4f - 3f /* descsz */; \ @@ -223,7 +223,7 @@ .popsection #else /* !__STDC__, i.e. -traditional */ #define ELFNOTE(name, type, desctype, descdata) \ -.pushsection .note.name ; \ +.pushsection .note.name,"",@note; \ .align 4 ; \ .long 2f - 1f /* namesz */; \ .long 4f - 3f /* descsz */; \ --- But there's even more problems... rtc0: [XEN] xen_rtc_gettime rtc0: [XEN] xen_rtc_gettime: wallclock 1364233979 sec; 99989 nsec rtc0: [XEN] xen_rtc_gettime: uptime 76890 sec; 166126554 nsec rtc0: [XEN] xen_rtc_gettime: TOD 1364310870 sec; 166126543 nsec start_init: trying /sbin/init pid 26 (sh), uid 0: exited on signal 4 panic: removing pages from non-current pmap cpuid = 0 KDB: enter: panic [ thread pid 26 tid 100037 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db> bt Tracing pid 26 tid 100037 td 0xc25e4900 kdb_enter(c03f8ad8,c03f8ad8,c04321de,ccf7699c,c04321de,...) at kdb_enter+0x3d/frame 0xccf76930 kassert_panic(c047c478,100,c04321de,ccf7699c,ccf7699c,...) at kassert_panic+0x232/frame 0xccf7696c kassert_panic(c04321de,c0431504,e0a,7bc,c044fe94,...) at kassert_panic+0xea/frame 0xccf76990 pmap_remove_pages(c2427638,c064bd74,8,c2427638,c248c8b8,...) at pmap_remove_pages+0xb3/frame 0xccf76a00 vmspace_exit(c25e4900,0,c03f2588,140,4,...) at vmspace_exit+0xb1/frame 0xccf76a28 exit1(c25e4900,4,1a,c248cacc,0,...) at exit1+0x654/frame 0xccf76a88 sigexit(c25e4900,4,c03f8b70,b0a,c0153a4f,...) at sigexit+0xc7f/frame 0xccf76c20 postsig(4,0,c03fee92,10d,0,...) at postsig+0x3b2/frame 0xccf76cdc ast(ccf76d18) at ast+0x388/frame 0xccf76d0c vm86_biosret() at vm86_biosret+0x9c/frame 0xbf7fcba8 >From ef73078b37f283401159119538b8ac85bbd512d6 Mon Sep 17 00:00:00 2001 From: Roger Pau Monne Date: Tue, 26 Mar 2013 12:39:58 +0100 Subject: [PATCH] xen: fix ELFNOTE macro Add an empty flag and the corresponding type of section to pushsection. --- sys/i386/include/asmacros.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/i386/include/asmacros.h b/sys/i386/include/asmacros.h index c1c3f64..474dfe1 100644 --- a/sys/i386/include/asmacros.h +++ b/sys/i386/include/asmacros.h @@ -211,7 +211,7 @@ #ifdef __STDC__ #define ELFNOTE(name, type, desctype, descdata...) \ -.pushsection .note.name ; \ +.pushsection .note.name,
Re: [Xen-users] Trouble booting FreeBSD i386 PV DomU
On 31/03/13 19:45, Cherry G.Mathew wrote: > > On 21/02/13 10:18, tech mailinglists wrote: >> Hello all, >> >> I have created a FreeBSD PV DomU image formatted with ZFS. I compiled >> FreeBSD with KERNCONF=XEN for the kernel and the normal world and >> distribution target. Then I transfered it to a Debian Dom0 with Xen 4.2.1. >> >> I tried to boot the image befor I migrate it to LVM and I now get teh >> following output: >> > > [...] > >> run_interrupt_driven_hooks: still waiting after 300 seconds for >> xenbus_free_evtchn >> panic: run_interrupt_driven_config_hooks: waited too long >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 0 tid 10 ] >> Stopped at kdb_enter+0x3a: movl$0,kdb_why >> db> > > > Try see if patch below should help the boot a bit along. The problem is already solved, it was crashing because blkback in Dom0 was not correctly working -- nothing to do with FreeBSD. The 9.x releases work correctly, the problem is with HEAD and the backtrace I've posted. BTW, if you wish to try HEAD you will need the ELFNOTE patch I've posted and boot with "hw.mca.enabled=0" to get to the panic I've posted earlier. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen and the art of the Linux Foundation
On 13/05/13 15:22, Adrian Chadd wrote: > Hi all, > > Now that the Xen project is moving under the umbrella of the Linux > foundation, what's that mean for Xen on non-Linux platforms? Xen source code and licensing is going to stay exactly the same. Could you be a little bit more explicit about the concerns? The major benefit is that the guardian of the project is no longer just Citrix, so Xen is more vendor neutral. Regards, Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVHVM call for testing
On 16/05/13 11:30, Sergey Nasonov wrote: > Hello. > > > > I have get problem running XENHVM kernel. > > FreeBSD VM was created based on template "Other install media" > > Fetching from git and compilation was fine. > > > > > > > > Unfortunately I cant copy VM screen output from XenCenter console so > write this by hand. > > > > run_interrupt_driven_hooks: still waiting after 60 seconds for > xenbusb_nop_confighook_cb > > run_interrupt_driven_hooks: still waiting after 120 seconds for > xenbusb_nop_confighook_cb > > run_interrupt_driven_hooks: still waiting after 180 seconds for > xenbusb_nop_confighook_cb > > run_interrupt_driven_hooks: still waiting after 240 seconds for > xenbusb_nop_confighook_cb > > run_interrupt_driven_hooks: still waiting after 300 seconds for > xenbusb_nop_confighook_cb > > panic: run_interrupt_driven_config_hooks: waited too long > > cpuid = 0 > > KDB: enter: panic > > [ thread pid 0 tid 10 ] > > Stopped at kdb_enter+0x3e: movq $0,kdb_why > > > > I am running this VM on XenServer 6.1 > > > > xe vm-list name-label="FreeBSD 10 pvhvm" params=all > > uuid ( RO) : f5b51518-5e6a-5f0b-1539-07e97f91ff6e > > name-label ( RW): FreeBSD 10 pvhvm > > name-description ( RW): Experimental from > git://xenbits.xen.org/people/royger/freebsd.git > > user-version ( RW): 1 > > is-a-template ( RW): false > > is-a-snapshot ( RO): false > > snapshot-of ( RO): > > snapshots ( RO): > > snapshot-time ( RO): 19700101T00:00:00Z > > snapshot-info ( RO): > > parent ( RO): > > children ( RO): > > is-control-domain ( RO): false > > power-state ( RO): running > > memory-actual ( RO): 1073688576 > > memory-target ( RO): > > memory-overhead ( RO): 11534336 > > memory-static-max ( RW): 1073741824 > > memory-dynamic-max ( RW): 1073741824 > > memory-dynamic-min ( RW): 1073741824 > > memory-static-min ( RW): 134217728 > > suspend-VDI-uuid ( RW): > > suspend-SR-uuid ( RW): a5b07c91-b940-d1c8-6822-3ef2517cca89 > > VCPUs-params (MRW): > > VCPUs-max ( RW): 1 > > VCPUs-at-startup ( RW): 1 > > actions-after-shutdown ( RW): Destroy > > actions-after-reboot ( RW): Restart > > actions-after-crash ( RW): Restart > > console-uuids (SRO): 5ec0c160-cada-1bd1-fbea-967e5b8a3bd4 > > platform (MRW): timeoffset: 0; nx: true; acpi: 1; apic: true; pae: true; > viridian: true > > allowed-operations (SRO): changing_dynamic_range; hard_reboot; > hard_shutdown; pause; snapshot > > current-operations (SRO): > > blocked-operations (MRW): > > allowed-VBD-devices (SRO): > > allowed-VIF-devices (SRO): > > possible-hosts ( RO): > > HVM-boot-policy ( RW): BIOS order > > HVM-boot-params (MRW): order: cd > > HVM-shadow-multiplier ( RW): 1.000 > > PV-kernel ( RW): > > PV-ramdisk ( RW): > > PV-args ( RW): > > PV-legacy-args ( RW): > > PV-bootloader ( RW): > > PV-bootloader-args ( RW): > > last-boot-CPU-flags ( RO): vendor: GenuineIntel; features: > 0004e33d-bfebfbff-0001-20100800 > > last-boot-record ( RO): > > resident-on ( RO): f20889e5-3395-4094-bec3-9e66cbdee395 > > affinity ( RW): f20889e5-3395-4094-bec3-9e66cbdee395 > > other-config (MRW): vgpu_pci: ; base_template_name: Other install media; > mac_seed: 91eceff7-7c2c-5222-5bb4-6f0fb80061c4; install-methods: cdrom > > dom-id ( RO): 53 > > recommendations ( RO): field="memory-static-max" max="137438953472" /> field="vcpus-max" max="16" /> max="7" /> > > xenstore-data (MRW): vm-data: > > ha-always-run ( RW) [DEPRECATED]: false > > ha-restart-priority ( RW): > > blobs ( RO): > > start-time ( RO): 20130516T09:52:35Z > > install-time ( RO): 20130515T12:30:44Z > > VCPUs-number ( RO): 1 > > VCPUs-utilisation (MRO): > > os-version (MRO): > > PV-drivers-version (MRO): > > PV-drivers-up-to-date ( RO): > > memory (MRO): > > disks (MRO): > > networks (MRO): > > other (MRO): > > live ( RO): > > guest-metrics-last-updated ( RO): > > cooperative ( RO) [DEPRECATED]: > > protection-policy ( RW): > > is-snapshot-from-vmpp ( RO): false > > tags (SRW): > > appliance ( RW): > > start-delay ( RW): 0 > > shutdown-delay ( RW): 0 > > order ( RW): 0 > > version ( RO): 0 > > > > > > Which additional info can I provide? Hello Sergey, Thanks for testing this, I'm afraid I'm not really familiar with XenServer or XenCenter. It looks like Linux users are also running into problems when trying to setup Linux PVHVMs on XenServer 6.1: http://discussions.citrix.com/index.php?/topic/315560-pvhvm-on-xenserver-61-xen-platform-blacklisted-by-host/ Could you login into your Dom0 and provide the output of `xenstore-ls -fp` while the FreeBSD PVHVM is running? Also, did the XENHVM FreeBSD kernel used to work without my changes? Thanks, Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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: on xenstore0 > > With a XENHVM kernel from FreeBSD HEAD the next line after that is >> xbd0: 10240MB 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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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=0x1783fbff Features2=0x81b82201 AMD Features=0x28100800 AMD Features2=0x1 real memory = 4286578688 (4088 MB) avail memory = 3961323520 (3777 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: 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 irqs 0-47 on motherboard kbd1 at kbdmux0 xen_et0: on motherboard Event timer "XENTIMER" frequency 10 Hz quality 950 Timecounter "XENTIMER" frequency 10 Hz quality 950 acpi0: on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 cpu4: on acpi0 cpu5: on acpi0 cpu6: on acpi0 cpu7: on acpi0 cpu8: on acpi0 cpu9: on acpi0 cpu10: on acpi0 cpu11: on acpi0 cpu12: on acpi0 cpu13: on acpi0 cpu14: on acpi0 cpu15: on acpi0 cpu16: on acpi0 cpu17: on acpi0 cpu18: on acpi0 cpu19: on acpi0 cpu20: on acpi0 cpu21: on acpi0 cpu22: on acpi0 cpu23: on acpi0 cpu24: on acpi0 cpu25: on acpi0 cpu26: on acpi0 cpu27: on acpi0 cpu28: on acpi0 cpu29: on acpi0 cpu30: on acpi0 cpu31: on acpi0 hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 6250 Hz quality 950 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 Timecounte
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é 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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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é 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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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é <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é <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: 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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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 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 Sponsored by: The FreeBSD Foundation, Semihalf Thanks for the testing, Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVHVM call for testing
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. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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 # make install Maybe the ISO you picked as a broken ports snapshot? ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] FreeBSD PVHVM call for testing
On 28/05/13 23:33, Colin Percival wrote: > 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. 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? > 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? ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] FreeBSD PVHVM call for testing
On 29/05/13 19:22, Matt Wilson wrote: > 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. 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. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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é 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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVHVM call for testing
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 Some notes on this branch, I've mainly tested it with Xen 4.3 (unstable) because previous Xen versions have problems with the PV clock used in PVHVM when migrating. In order to be able to migrate a PVHVM guest you will need to add tsc_mode="native_paravirt" to your config file or apply the following patch to Xen: http://marc.info/?l=xen-devel&m=137036010517331 I would say that migration across the 4.x series will work without problems (because they all have support for vector callback injection), but migrating from 4.x to 3.x will certainly not work. On the other hand, migrating a guest started on 3.4 to 4.0 should work, although I have not tested it. Also, if the migration process fails for some reason, resuming the original guest on the sender side will leave the VM without working nics and disks, this is a problem with netfront and blkfront not being able to resume after suspension if the guest was not actually migrated. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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é <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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: KERNCONF=XENHVM FAILED to build
On 12/06/13 18:18, J wrote: > make buildkernel KERNCONF=XENHVM failed on FreeBSD 9.1 release: > > > ld -d -warn-common -r -d -o zlib.ko.debug zlib.o > :> export_syms > awk -f /usr/src/sys/conf/kmod_syms.awk zlib.ko.debug export_syms | xargs > -J% objcopy % zlib.ko.debug > objcopy --only-keep-debug zlib.ko.debug zlib.ko.symbols > objcopy --strip-debug --add-gnu-debuglink=zlib.ko.symbols zlib.ko.debug > zlib.ko > 1 error > *** [buildkernel] Error code 2 > 1 error > *** [buildkernel] Error code 2 > 1 error > > > Hello, Could you post the actual error that caused the compilation to fail? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVHVM call for testing
On 19/06/13 13:13, Jeroen van der Ham wrote: > Hi, > > I've just built a new kernel based on pvhvm_v17, but it panicked on boot. > > I still have a xen console attached, so I can provide additional information > if someone gives me the right commands. > > Jeroen. > Could you provide the boot log of the DomU, backtrace, Xen version and Dom0 kernel version? ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
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é 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=0x1781fbff > Features2=0x80802001 > AMD Features=0xe2500800 > AMD Features2=0x1f3 > real memory = 536870912 (512 MB) > avail memory = 472260608 (450 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > 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 irqs 0-47 on motherboard > kbd1 at kbdmux0 > xen_et0: on motherboard > Event timer "XENTIMER" frequency 10 Hz quality 950 > Timecounter "XENTIMER" frequency 10 Hz quality 950 > acpi0: on motherboard > acpi0: Power Button (fixed) > acpi0: Sleep Button (fixed) > acpi0: reservation of 0, a (3) failed > cpu0: on acpi0 > cpu1: on acpi0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > atrtc0: 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: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > isab0: at device 1.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc300-0xc30f at device 1.1 on pci0 > ata0: at channel 0 on atapci0 > ata1: at channel 1 on atapci0 > pci0: at device 1.3 (no driver attached) > vgapci0: mem > 0xf000-0xf1ff,0xf300-0xf3000fff at device 2.0 on pci0 > xenpci0: port 0xc000-0xc0ff mem 0xf200-0xf2ff > irq 28 at device 3.0 on pci0 > xenstore0: on xenpci0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse Explorer, device ID 4 > fdc0: 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: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > orm0: at iomem 0xc9000-0xc97ff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 > fdc0: No FDOUT register! > Timecounters tick every 10.000 msec > xenbusb_front0: on xenstore0 > cd0 at ata1 bus 0 scbus1 target 0 lun 0 > cd0: 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: at device/vif/0 on xenbusb_front0 > xn0: Ethernet address: 00:16:3e:2f:b7:22 > xn1: at device/vif/1 on xenbusb_front0 > xn1: Ethernet address: 00:16:3e:3e:64:c5 > xenbusb_back0: on xenstore0 > xctrl0: on xenstore0 > xn0: backend features: feature-sg feature-gso-tcp4 > xn1: backend featur
Re: FreeBSD PVHVM call for testing
On 19/06/13 14:33, Jeroen van der Ham wrote: > > On 19 Jun 2013, at 14:20, Roger Pau Monné 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. :) D'oh, I've completely forgot about the wiki page, it's updated now, thanks for the pointer. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: XENHVM on -curent useless
On 10/07/13 17:54, Sean Bruno wrote: > Just got a rootbsd.net instance and the 9.1r XENHVM that they provided > me works great. > > Attempted to boot -current on their systems and the XENHVM kernel > panic'd when it could find any hardware timers. This is a pretty > serious regression that I'll bisect this weekend if nobody is looking at > it. Could you post the boot log and the panic with a backtrace? ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: KERNCONF=XENHVM FAILED to build
On 11/07/13 13:11, Jeroen van der Ham wrote: > Hi, > > I've been trying to build kernel on FreeBSD 9.0 also, and it fails for me as > well: > > clang -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -Wmissing-include-dirs -fdiagnostics-show-option > -Wno-error-tautological-compare -Wno-error-empty-body > -Wno-error-parentheses-equality -nostdinc -I. > -I/usr/home/jeroen/freebsd/sys -I/usr/home/jeroen/freebsd/sys/contrib/altq > -I/usr/home/jeroen/freebsd/sys/contrib/libfdt -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer > -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -Werror /usr/home/jeroen/freebsd/sys/kern/vfs_mountroot.c > /usr/home/jeroen/freebsd/sys/kern/vfs_mountroot.c:270:2: error: expression > result unused [-Werror,-Wunused-value] > VFS_ROOT(mporoot, LK_EXCLUSIVE, &vporoot); > ^ > /usr/home/jeroen/freebsd/sys/sys/mount.h:668:2: note: expanded from: > _rc; }) > ^~~ > 1 error generated. > *** Error code 1 > > Stop in /usr/obj/usr/home/jeroen/freebsd/sys/GENERIC. > *** Error code 1 This doesn't seem to be related to the Xen support at all, and also you are building the GENERIC kernel, not XENHVM. I guess it would be better to move this thread to freebsd-current ML (if errors are not related to Xen code). ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: XENHVM on -curent useless
On 10/07/13 18:41, Sean Bruno wrote: > On Wed, 2013-07-10 at 18:15 +0200, Roger Pau Monné wrote: >> On 10/07/13 17:54, Sean Bruno wrote: >>> Just got a rootbsd.net instance and the 9.1r XENHVM that they provided >>> me works great. >>> >>> Attempted to boot -current on their systems and the XENHVM kernel >>> panic'd when it could find any hardware timers. This is a pretty >>> serious regression that I'll bisect this weekend if nobody is looking at >>> it. >> >> Could you post the boot log and the panic with a backtrace? >> > > > Yeah, I'll do that in a bit. I'm doing a testcompile on my instance at > the moment, but the panic string was: > > panic: No usable event timer found > > I'm rebuilding world/kernel at the moment, so it'll be a couple of hours > before I can fire it up. That's strange, I've just compiled a recent XENHVM kernel and it seems to work just fine, the tip commit is: commit e42a32794c6657516febef7a44fad00ddb24f2fa Author: theraven Date: Wed Jul 10 10:57:09 2013 + Report error for out-of-range numerical inputs. Requested by brooks. Are you using i386 or amd64? Also, could you post the Xen version you are using and the config file for the guest? Here is my boot log: Booting... 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=000f len=0001 SMAP type=01 base=0010 len=7f6ff000 SMAP type=02 base=7f7ff000 len=1000 SMAP type=02 base=fc00 len=0400 Table 'FACP' at 0xfc009a20 Table 'APIC' at 0xfc009b20 APIC: Found table at 0xfc009b20 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: disabled MADT: Found CPU APIC ID 16 ACPI ID 8: disabled MADT: Found CPU APIC ID 18 ACPI ID 9: disabled MADT: Found CPU APIC ID 20 ACPI ID 10: disabled MADT: Found CPU APIC ID 22 ACPI ID 11: disabled MADT: Found CPU APIC ID 24 ACPI ID 12: disabled MADT: Found CPU APIC ID 26 ACPI ID 13: disabled MADT: Found CPU APIC ID 28 ACPI ID 14: disabled MADT: Found CPU APIC ID 30 ACPI ID 15: disabled MADT: Found CPU APIC ID 32 ACPI ID 16: disabled MADT: Found CPU APIC ID 34 ACPI ID 17: disabled MADT: Found CPU APIC ID 36 ACPI ID 18: disabled MADT: Found CPU APIC ID 38 ACPI ID 19: disabled MADT: Found CPU APIC ID 40 ACPI ID 20: disabled MADT: Found CPU APIC ID 42 ACPI ID 21: disabled MADT: Found CPU APIC ID 44 ACPI ID 22: disabled MADT: Found CPU APIC ID 46 ACPI ID 23: disabled MADT: Found CPU APIC ID 48 ACPI ID 24: disabled MADT: Found CPU APIC ID 50 ACPI ID 25: disabled MADT: Found CPU APIC ID 52 ACPI ID 26: disabled MADT: Found CPU APIC ID 54 ACPI ID 27: disabled MADT: Found CPU APIC ID 56 ACPI ID 28: disabled MADT: Found CPU APIC ID 58 ACPI ID 29: disabled MADT: Found CPU APIC ID 60 ACPI ID 30: disabled MADT: Found CPU APIC ID 62 ACPI ID 31: disabled MADT: Found CPU APIC ID 64 ACPI ID 32: disabled MADT: Found CPU APIC ID 66 ACPI ID 33: disabled MADT: Found CPU APIC ID 68 ACPI ID 34: disabled MADT: Found CPU APIC ID 70 ACPI ID 35: disabled MADT: Found CPU APIC ID 72 ACPI ID 36: disabled MADT: Found CPU APIC ID 74 ACPI ID 37: disabled MADT: Found CPU APIC ID 76 ACPI ID 38: disabled MADT: Found CPU APIC ID 78 ACPI ID 39: disabled MADT: Found CPU APIC ID 80 ACPI ID 40: disabled MADT: Found CPU APIC ID 82 ACPI ID 41: disabled MADT: Found CPU APIC ID 84 ACPI ID 42: disabled MADT: Found CPU APIC ID 86 ACPI ID 43: disabled MADT: Found CPU APIC ID 88 ACPI ID 44: disabled MADT: Found CPU APIC ID 90 ACPI ID 45: disabled MADT: Found CPU APIC ID 92 ACPI ID 46: disabled MADT: Found CPU APIC ID 94 ACPI ID 47: disabled MADT: Found CPU APIC ID 96 ACPI ID 48: disabled MADT: Found CPU APIC ID 98 ACPI ID 49: disabled MADT: Found CPU APIC ID 100 ACPI ID 50: disabled MADT: Found CPU APIC ID 102 ACPI ID 51: disabled MADT: Found CPU APIC ID 104 ACPI ID 52: disabled MADT: Found CPU APIC ID 106 ACPI ID 53: disabled MADT: Found CPU APIC ID 108 ACPI ID 54: disabled MADT: Found CPU APIC ID 110 ACPI ID 55: disabled MADT: Found CPU APIC ID 112 ACPI ID 56: disabled MADT: Found CPU APIC ID 114 ACPI ID 57: disabled MADT: Found CPU APIC ID 116 ACPI ID 58: disabled MADT: Found CPU APIC ID 118 ACPI ID 59: disabled MADT: Found CPU APIC ID
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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVHVM call for testing
On 22/07/13 10:40, Jeroen van der Ham wrote: > Hi, > > On 22 Jul 2013, at 10:29, Roger Pau Monné wrote: >> Is your guest running a 32bit or a 64bit kernel? > > $ uname -a > FreeBSD positron.dckd.nl 10.0-CURRENT FreeBSD 10.0-CURRENT #0 > r+a09eac7-dirty: Wed Jul 17 17:51:10 CEST 2013 > root@image01:/usr/obj/usr/home/jeroen/freebsd/sys/XENHVM amd64 > >> >> Could you also provide the config file used to launch your guest and the >> Xen and Dom0 kernel versions? > > Guest config: > > kernel = '/usr/lib/xen-4.0/boot/hvmloader' > device_model = '/usr/lib/xen-4.0/bin/qemu-dm' > builder = 'hvm' > shadow_memory = 8 Are you setting the shadow memory size manually because your hardware lacks HAP support? > memory = 512 > name = "positron" > vcpus = 2 > cpus = "2-7" > maxvcpus = 4 > xen_shell = 'root, jeroen' This doesn't seem like a standard xl config option. > > vif = [ > 'type=vifname=positron.wan,bridge=br-wan,mac=00:16:3E:2F:AD:99,ip=94.142.246.99' > , > 'type=vifname=positron.lan,bridge=br-lan,mac=00:16:3E:0D:96:5C,ip=10.20.0.99' > ] > > disk = ['phy:/xen/domains/positron/positron-disk1,hda,w'] > > xen_platform_pci=1 > boot = 'c' > sdl=0 > stdvga=0 > serial='pty' > > > Xen 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: 6865 > 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 I've set up a XENHVM system with 256MB of RAM and swap and this is what I see when doing a make buildkernel: [root@ ~]# swapinfo Device 1K-blocks UsedAvail Capacity /dev/ada0p3 1048540 351116 69742433% I don't see any messages on the console or anything else, the system seems to be sluggish while doing the build, but that's quite normal when using only 256MB of RAM. This test was done using the pvhvm_20 branch, but it should not contain any significant code changes in comparison with pvhvm_v19 (it's just a rebase on top of HEAD and a reorder of patches). Could this be because you are using a 9 userland with a 10 kernel? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: kern/180788: [xen] [panic] XEN PV kernel 9.2-BETA1 panics on boot
The following reply was made to PR kern/180788; it has been noted by GNATS. From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= To: , Cc: Subject: Re: kern/180788: [xen] [panic] XEN PV kernel 9.2-BETA1 panics on boot Date: Fri, 26 Jul 2013 16:53:04 +0200 This issue can be solved by reverting commit r244806. However this is not a long term option, r244806 just exposes a bug in Xen PV pmap code which should be fixed. It seems like Xen pmap is not able to cope with two processes sharing the same address space. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: CFT: replacing XENHVM kernel config with GENERIC + xenhvm.ko
On 27/08/13 07:08, Colin Percival wrote: > Hi all, > > I've attached a patch which eliminates the XENHVM kernel configuration and > instead allows FreeBSD to run under Xen/HVM with PV drivers by loading a > new xenhvm.ko module from the boot loader. This will mean that FreeBSD > virtual machines running under Xen/HVM will be able to run "straight off > the ISO" binaries; this will also mean they will be able to use FreeBSD > Update to update the kernel. > > I have spent about 10 minutes testing this in Amazon EC2. Please help me > out by doing some more testing. ;-) Hello Colin, I'm sorry to say this, but I'm not sure this is the best way to move forward, I would prefer to just have the files merged directly into the GENERIC kernel rather than having to load a module. Also with the PVHVM changes I've posted earlier I'm modifying some common files, which cannot be put into a module, so it makes me wonder if it's worth it to have some Xen specific code into a module while the rest of it is already integrated into GENERIC. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: XenServer 6.2 tools for FreeBSD 9 'Guest'?
On 28/08/13 17:31, Karl Pielorz wrote: > > Hi, > > We've got XenServer now running a couple of FreeBSD 9.2-RC2 VM's > (running the XENHVM kernel). > > Is there any up to date 'xen tools' setup guide or anything anywhere we > can look at? > > I've seen 'xen-tools' in the ports collection - but once installed it > doesn't seem to do a lot. I'm looking to enable things like suspending > VM's and migration etc. Using the XENHVM kernel should already provide you with everything needed for migration (suspension and resume). From a quick look at the xen-tools package, it contains utilities to interact with xenstore, which you probably don't need. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFR] Event channel Interrupts and unified Xen interrupt infrastructure.
On 29/08/13 18:32, Justin T. Gibbs wrote: > I've been working to get the next chunk of Spectra/Roger Pau Monné Xen work > into head. The latest version of the patch I'm working on can be found here: > > http://people.freebsd.org/~gibbs/xen_intr.diff > > I will continue my testing today and commit it tonight unless I hear > complaints. Comments, corrections, improvements, and bug reports welcome. Hello Justin, Thanks, the patch looks OK to me, just one minor nit, could you add: Sponsored by: Citrix Systems R&D to the commit message. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFR] Event channel Interrupts and unified Xen interrupt infrastructure.
On 29/08/13 21:15, Colin Percival wrote: > On 08/29/13 09:32, Justin T. Gibbs wrote: >> I've been working to get the next chunk of Spectra/Roger Pau Monné Xen work >> into head. The latest version of the patch I'm working on can be found here: >> >> http://people.freebsd.org/~gibbs/xen_intr.diff >> >> I will continue my testing today and commit it tonight unless I hear >> complaints. Comments, corrections, improvements, and bug reports welcome. > > Could this patch be split into functional and non-functional components? It's > distracting having everything mixed up together in a single megapatch. Even > committing the s/unlikely/__predict_false/ separately would help. > > How do you intend to have Xen HVM work in the GENERIC kernel configuration? > Will you be adding 'options XENHVM' to GENERIC? I'm currently working on this, I expect to have a patch ready tomorrow (I still have to test it on bare metal). Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFR] Event channel Interrupts and unified Xen interrupt infrastructure.
On 29/08/13 21:29, Justin T. Gibbs wrote:
> On Aug 29, 2013, at 1:15 PM, Colin Percival wrote:
>
>> On 08/29/13 09:32, Justin T. Gibbs wrote:
>>> I've been working to get the next chunk of Spectra/Roger Pau Monné Xen work
>>> into head. The latest version of the patch I'm working on can be found
>>> here:
>>>
>>> http://people.freebsd.org/~gibbs/xen_intr.diff
>>>
>>> I will continue my testing today and commit it tonight unless I hear
>>> complaints. Comments, corrections, improvements, and bug reports welcome.
>>
>> Could this patch be split into functional and non-functional components?
>> It's
>> distracting having everything mixed up together in a single megapatch. Even
>> committing the s/unlikely/__predict_false/ separately would help.
>
> It could, but it would delay an already long delayed process in getting this
> work into the tree.
>
>> How do you intend to have Xen HVM work in the GENERIC kernel configuration?
>> Will you be adding 'options XENHVM' to GENERIC?
I'm attaching a patch that introduces Xen support into GENERIC, it can
be found as usual on my git tree:
http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/xenhvm_merge_generic
It builds on top of my previous PVHVM series, which is now halfway
committed to HEAD. I've tested it under Xen using the GENERIC kernel
(for both i386 and amd64), and everything seems to be fine, and I've
also tested it on bare metal amd64, which also seems to be running fine.
Roger.
>From e4303d73826577e7a9bd3031d201aa02a31b720a Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Thu, 29 Aug 2013 12:00:50 +0200
Subject: [PATCH] xen: merge XENHVM into GENERIC
Merge Xen PVHVM support into generic for both amd64 and i386.
sys/amd64/amd64/mp_machdep.c:
sys/amd64/include/cpu.h:
sys/i386/i386/mp_machdep.c:
sys/i386/include/cpu.h:
- Introduce two new CPU hooks, for initialization and resume
purposes. This allows us to get rid of the XENHVM ifdefs in
mp_machdep, and also sets some hooks into common code that can be
used by others.
sys/amd64/conf/XENHVM:
sys/i386/conf/XENHVM:
- Remove this configs now that GENERIC has builtin support for Xen.
sys/kern/subr_smp.c:
- Make sure there are no pending IPIs when suspending with the
GENERIC kernel.
sys/x86/xen/hvm.c:
- Add cpu resume operation, that will be called from mp_machdep using
the new hooks.
- Remove the CPU_FOREACH call in xen_hvm_init, it is not needed, and
at the point were xen_hvm_init gets called we still don't know how
many CPUs there are on the system.
- Gate xen_hvm_init_cpu only to systems running under Xen.
sys/x86/xen/xen_intr.c:
- Gate the setup of event channels only to systems running under Xen.
---
sys/amd64/amd64/mp_machdep.c | 33 +++---
sys/amd64/conf/GENERIC |4 +++
sys/amd64/conf/XENHVM| 22
sys/amd64/include/cpu.h |2 +
sys/i386/conf/GENERIC|4 +++
sys/i386/conf/XENHVM | 22
sys/i386/i386/mp_machdep.c | 33 +++---
sys/i386/include/cpu.h |2 +
sys/kern/subr_smp.c |2 -
sys/x86/xen/hvm.c| 45 -
sys/x86/xen/xen_intr.c |3 ++
11 files changed, 74 insertions(+), 98 deletions(-)
delete mode 100644 sys/amd64/conf/XENHVM
delete mode 100644 sys/i386/conf/XENHVM
diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
index def7335..81c2fe6 100644
--- a/sys/amd64/amd64/mp_machdep.c
+++ b/sys/amd64/amd64/mp_machdep.c
@@ -71,10 +71,6 @@ __FBSDID("$FreeBSD$");
#include
#include
-#ifdef XENHVM
-#include
-#endif
-
#define WARMBOOT_TARGET0
#define WARMBOOT_OFF (KERNBASE + 0x0467)
#define WARMBOOT_SEG (KERNBASE + 0x0469)
@@ -126,7 +122,9 @@ static u_long *ipi_hardclock_counts[MAXCPU];
/* Machinery for allowing non-native IPI mechanisms */
DPCPU_DEFINE(struct cpu_ops, cpu_ops) = {
- .ipi_vectored = lapic_ipi_vectored
+ .ipi_vectored = lapic_ipi_vectored,
+ .cpu_init = NULL,
+ .cpu_resume = NULL,
};
extern inthand_t IDTVEC(fast_syscall), IDTVEC(fast_syscall32);
@@ -157,7 +155,7 @@ int cpu_apic_ids[MAXCPU];
int apic_cpuids[MAX_APIC_ID + 1];
/* Holds pending bitmap based IPIs per CPU */
-static volatile u_int cpu_ipi_pending[MAXCPU];
+volatile u_int cpu_ipi_pending[MAXCPU];
static u_int boot_address;
static int cpu_logical;/* logical cpus per core */
@@ -621,6 +619,7 @@ init_secondary(void)
u_int cpuid;
int cpu, gsel_tss, x;
struct region_descriptor ap_gdt;
+ struct cpu_ops *cpu_ops;
/* Set by the startup code for us to use */
blkback making assumptions about the id of the requests
Hello,
While playing with driver domains using FreeBSD I've found out that
blkback in FreeBSD makes assumptions about the id of a request instead
of actually using the id of the request on the shared ring. This seems
wrong to me, since a frontend might choose whatever ids it like for the
requests (like using 100-131 instead of 0-31). The patch attached fixes
it by copying the id from the request on the ring to blkback internal
request structure.
Roger.
>From 01c3edc4446b113ec85537bb75c56c6072c4ee49 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Mon, 2 Sep 2013 15:51:47 +0200
Subject: [PATCH] xen-blkback: don't make assumptions about request ids
Blkback makes assumptions about the id of the request it received
from the frontend, this patch fixes it by always honoring the
id passed from the frontend instead of assuming there's an implicit
order in the id of the requests.
---
sys/dev/xen/blkback/blkback.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sys/dev/xen/blkback/blkback.c b/sys/dev/xen/blkback/blkback.c
index 2a220c4..500b347 100644
--- a/sys/dev/xen/blkback/blkback.c
+++ b/sys/dev/xen/blkback/blkback.c
@@ -1239,6 +1239,7 @@ xbb_get_resources(struct xbb_softc *xbb, struct
xbb_xen_reqlist **reqlist,
nreq->reqlist = *reqlist;
nreq->req_ring_idx = ring_idx;
+ nreq->id = ring_req->id;
if (xbb->abi != BLKIF_PROTOCOL_NATIVE) {
bcopy(ring_req, &nreq->ring_req_storage, sizeof(*ring_req));
--
1.7.7.5 (Apple Git-26)
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: blkback making assumptions about the id of the requests
On 02/09/13 22:03, Justin T. Gibbs wrote:
> On Sep 2, 2013, at 11:58 AM, Roger Pau Monné wrote:
>
>> Hello,
>>
>> While playing with driver domains using FreeBSD I've found out that
>> blkback in FreeBSD makes assumptions about the id of a request instead
>> of actually using the id of the request on the shared ring. This seems
>> wrong to me, since a frontend might choose whatever ids it like for the
>> requests (like using 100-131 instead of 0-31). The patch attached fixes
>> it by copying the id from the request on the ring to blkback internal
>> request structure.
>>
>> Roger.
>
> It looks to me like the id is set in xbb_dispatch_io(). Why it is done there
> and not earlier, I don't recall.
Sorry, I've missed to spot that the id is set there, the problem is that
requests of type BLKIF_OP_FLUSH_DISKCACHE never reach that point, so
they end up having incorrect requests ids. I've reworded the commit
message and removed the late setting of the request id, now it is set
earlier so requests of type flush also have a valid id when writing the
response on the ring.
From 80dc3cbf5ed88be890d28ae198ab69968caf9d63 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Mon, 2 Sep 2013 15:51:47 +0200
Subject: [PATCH] xen-blkback: set request id correctly for flush OP
Originally the internal request id is set on xbb_dispatch_io, but
requests of type BLKIF_OP_FLUSH_DISKCACHE never reach this point, so
they end up having wrong request ids when writting the response on the
ring, breaking the frontend.
This patch fixes it by setting the request id for all request types
earlier, so that BLKIF_OP_FLUSH_DISKCACHE operations have the right
id.
---
sys/dev/xen/blkback/blkback.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sys/dev/xen/blkback/blkback.c b/sys/dev/xen/blkback/blkback.c
index 2a220c4..fa9a744 100644
--- a/sys/dev/xen/blkback/blkback.c
+++ b/sys/dev/xen/blkback/blkback.c
@@ -1239,6 +1239,7 @@ xbb_get_resources(struct xbb_softc *xbb, struct
xbb_xen_reqlist **reqlist,
nreq->reqlist = *reqlist;
nreq->req_ring_idx = ring_idx;
+ nreq->id = ring_req->id;
if (xbb->abi != BLKIF_PROTOCOL_NATIVE) {
bcopy(ring_req, &nreq->ring_req_storage, sizeof(*ring_req));
@@ -1608,7 +1609,6 @@ xbb_dispatch_io(struct xbb_softc *xbb, struct
xbb_xen_reqlist *reqlist)
req_ring_idx = nreq->req_ring_idx;
nr_sects = 0;
nseg = ring_req->nr_segments;
- nreq->id = ring_req->id;
nreq->nr_pages= nseg;
nreq->nr_512b_sectors = 0;
req_seg_idx = 0;
--
1.7.7.5 (Apple Git-26)
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Current problem reports assigned to freebsd-xen@FreeBSD.org
On 02/09/13 13:06, FreeBSD bugmaster wrote: > Note: to view an individual PR, use: > http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). > > The following is a listing of current problems submitted by FreeBSD users. > These represent problem reports covering all versions including > experimental development code and obsolete releases. > > > S Tracker Resp. Description > > o kern/180788 xen[xen] [panic] XEN PV kernel 9.2-BETA1 panics on boot This is due to bugs in i386 PV pmap, and was closed by reverting r244237 in 9.2, but the problem is still present in HEAD. > o kern/180403 xen[xen] Problems with GENERIC and XENHVM kernels with > Xe > o kern/180402 xen[xen] XEN kernel does not load in XenClient 4.5.5 This is a duplicate of kern/180403, which contains more info. > o kern/179814 xen[xen] mountroot fails with error=19 under Xen on > 9-STA This is due to the change from ad to ada for xbd devices, not really a bug IMHO. > o kern/176471 xen[xen] xn driver crash on detach Fixed. > o kern/176053 xen[xen] [patch] i386: Correct wrong usage of > vsnprintf() > o kern/175954 xen[xen] XENHVM xn network driver extreme packet loss > dur > o kern/175822 xen[xen] FreeBSD 9.1 does not work with Xen 4.0 I would say this is fixed, or at least I've never encountered this bug. > o kern/175757 xen[xen] [patch] xen pvhvm looses keyboard input from > VNC Fixed. > o kern/171873 xen[xen] xn network device floods warning in dmesg Never seen it on any Xen version and Dom0 kernel combination (already fixed?) > o kern/171118 xen[xen] FreeBSD XENHVM guest doesn't shutdown cleanly xl shutdown does the right thing, so I'm not sure if this bug is specific to XCP/XenServer toolstacks. > o kern/166174 xen[xen] Problems ROOT MOUNT ERROR > o kern/165418 xen[xen] Problems mounting root filesystem from XENHVM > o kern/164630 xen[xen] XEN HVM kernel: run_interrupt_driven_hooks: > stil > o kern/164450 xen[xen] Failed to install FreeeBSD 9.0-RELEASE from > CD i > o kern/162677 xen[xen] FreeBSD not compatible with "Current Stable > Xen" FreeBSD runs fine on 4.2, 4.3 and 4.4. > o kern/161318 xen[xen] sysinstall crashes with floating point > exception Never seen it on 9.x or HEAD. > o kern/155468 xen[xen] Xen PV i386 multi-kernel CPU system is not > worki > o kern/155353 xen[xen] [patch] put "nudging TOD" message under > boot_ver > o kern/154833 xen[xen]: xen 4.0 - DomU freebsd8.2RC3 i386, XEN > kernel. > o kern/154473 xen[xen] xen 4.0 - DomU freebsd8.1 i386, XEN kernel. > Not > o kern/154472 xen[xen] xen 4.0 - DomU freebsd8.1 i386 xen kernel > reboot > o kern/154428 xen[xen] xn0 network interface and PF - Massive > performan > o kern/153674 xen[xen] i386/XEN idle thread shows wrong percentages > o kern/153672 xen[xen] [panic] i386/XEN panics under heavy fork load > o kern/153620 xen[xen] Xen guest system clock drifts in AWS EC2 > (FreeBS Probably fixed by the new PV timer/clock implementation in HEAD. > o kern/153477 xen[xen] XEN pmap code abuses vm page queue lock > o kern/153150 xen[xen] xen/ec2: disable checksum offloading on > interfac > o kern/152228 xen[xen] [panic] Xen/PV panic with machdep.idle_mwait=1 > o kern/144629 xen[xen] FreeBSD 8-RELEASE XEN pvm networking doesn't > wor > o kern/143398 xen[xen] FreeBSD 8-RELEASE XEN pvm networking doesn't > wor > o kern/143340 xen[xen] FreeBSD 8-RELEASE XEN pvm networking doesn't > wor > f kern/143069 xen[xen] [panic] Xen Kernel Panic - Memory modified > after > f kern/135667 xenufs filesystem corruption on XEN DomU system Already fixed also I guess (specially regarding last message from Colin Percival). > f kern/135421 xen[xen] FreeBSD Xen PVM DomU network failure - > netfronc. > f kern/135178 xen[xen] Xen domU outgoing data transfer stall when > TSO i > p kern/135069 xen[xen] FreeBSD-current/Xen SMP doesn't function at > all > f i386/124516 xen[xen] FreeBSD-CURRENT Xen Kernel Segfaults when > config > o kern/118734 xen[xen] FreeBSD 6.3-RC1 and FreeBSD 7.0-BETA 4 fail > to b > > 39 problems total. > > ___ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" > ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Another blkback issue related to flush
Hello,
I've found another issue with blkback handling of flush operations, it
was incorrectly setting one of the bio parameters when using a block
device as backend. The attached patch fixes it, and also includes a
small fix to correctly set the operation when writing the response on
the ring (all responses written by FreeBSD blkback were of type
BLKIF_OP_READ, because nreq->operation was not set).
>From b6cd715b2a2fcff0321ccaafe9740082f15b5943 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Wed, 4 Sep 2013 18:33:22 +0200
Subject: [PATCH] xen-blkback: fix incorrect handling of flush for block
devices
When issuing a flush operation to a block device (from
xbb_dispatch_dev), bio->bio_caller1 was incorrectly set to
xbb_xen_req, when the bio callback (xbb_bio_done) specifically
expects bio_caller1 to be of type xbb_xen_reqlist.
Also set the request operation to match the one on the request from
the ring, so that when we write the reply the operation matches.
---
sys/dev/xen/blkback/blkback.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/sys/dev/xen/blkback/blkback.c b/sys/dev/xen/blkback/blkback.c
index fa9a744..58b53e7 100644
--- a/sys/dev/xen/blkback/blkback.c
+++ b/sys/dev/xen/blkback/blkback.c
@@ -1240,6 +1240,7 @@ xbb_get_resources(struct xbb_softc *xbb, struct
xbb_xen_reqlist **reqlist,
nreq->reqlist = *reqlist;
nreq->req_ring_idx = ring_idx;
nreq->id = ring_req->id;
+ nreq->operation = ring_req->operation;
if (xbb->abi != BLKIF_PROTOCOL_NATIVE) {
bcopy(ring_req, &nreq->ring_req_storage, sizeof(*ring_req));
@@ -2062,7 +2063,6 @@ xbb_dispatch_dev(struct xbb_softc *xbb, struct
xbb_xen_reqlist *reqlist,
{
struct xbb_dev_data *dev_data;
struct bio *bios[XBB_MAX_SEGMENTS_PER_REQLIST];
- struct xbb_xen_req *nreq;
off_tbio_offset;
struct bio *bio;
struct xbb_sg *xbb_sg;
@@ -2080,7 +2080,6 @@ xbb_dispatch_dev(struct xbb_softc *xbb, struct
xbb_xen_reqlist *reqlist,
bio_idx= 0;
if (operation == BIO_FLUSH) {
- nreq = STAILQ_FIRST(&reqlist->contig_req_list);
bio = g_new_bio();
if (unlikely(bio == NULL)) {
DPRINTF("Unable to allocate bio for BIO_FLUSH\n");
@@ -2094,10 +2093,10 @@ xbb_dispatch_dev(struct xbb_softc *xbb, struct
xbb_xen_reqlist *reqlist,
bio->bio_offset = 0;
bio->bio_data= 0;
bio->bio_done= xbb_bio_done;
- bio->bio_caller1 = nreq;
+ bio->bio_caller1 = reqlist;
bio->bio_pblkno = 0;
- nreq->pendcnt= 1;
+ reqlist->pendcnt = 1;
SDT_PROBE1(xbb, kernel, xbb_dispatch_dev, flush,
device_get_unit(xbb->dev));
--
1.7.7.5 (Apple Git-26)
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Another blkback issue related to flush
On 04/09/13 19:49, Justin T. Gibbs wrote: > On Sep 4, 2013, at 11:07 AM, Roger Pau Monné wrote: > >> Hello, >> >> I've found another issue with blkback handling of flush operations, it >> was incorrectly setting one of the bio parameters when using a block >> device as backend. The attached patch fixes it, and also includes a >> small fix to correctly set the operation when writing the response on >> the ring (all responses written by FreeBSD blkback were of type >> BLKIF_OP_READ, because nreq->operation was not set). > > It seems that the req's pendcnt is unused and can be culled. Otherwise, > looks good to me. Here's the patch I have in my tree now. Thanks for catching this one. The patch looks OK to me. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [CFR] Xen IPI patch
On 03/09/13 05:49, Justin T. Gibbs wrote: > In my continuing effort to get all of Roger's Xen enhancements into > FreeBSD, I'm just about finished reviewing the next patch in his > series. The current status of the patch can be found here: > > http://people.freebsd.org/~gibbs/xen_ipi.diff > > The main, and late breaking, wrinkle for this patch is the newly > committed PCID support form AMD64. I've done my best to translate > the updated assembly IPI handlers into the C equivalents needed for > Xen. But, I'm by no means an x86 assembly expert, and my current > Xen installation doesn't advertise PCID, so all of the new branches > I've added have yet to be tested. I also wonder if PVHVM guests > are supposed to perform the PCID work natively or use some other > Hypervisor functionality. PCID is supported inside of HVM containers, nothing special should be done in order to use this instructions. I've been able to test this on a system with PCID support, and everything seems to work fine, PCID is correctly detected and used by FreeBSD (when running under Xen). I've just rebased the PV IPI patch on top of Konstantin's latest PCID change: http://xenbits.xen.org/people/royger/0001-Implement-PV-IPIs-for-PVHVM-guests-and-further-conve.patch > > Other things I'm not happy about with the patch: > - hvm.c wants to use invltlb_globpcid(), but it is private > to pmap.c. I've moved it to cpufunc.h to be next to > invltlb(), but the definition of CR4_PGE (from specialreg.h) > isn't visible in all of the contexts that include cpufunc.h. > So I hackishly define it if necessary. Ick. There seems to be other places were cpufunc.h does this kind of nasty tricks. > - With the divergence of IPI handling between i386 and > amd64, x86/xen/hvm.c is growing too many ifdefs. Should > we delegate the definitions of the ipi functions to > amd64/xen/hvm.c and i386/xen/hvm.c? I will wait for this until we have a plan to merge native and Xen IPIs, right now I would leave all of them inside x86/xen/hvm.c > > - There's too much code duplication in xen_invlrng() > and some of the logic in the other handlers can probably > be tightened up. I've reduced code duplication a little bit there by creating a small inline function that contains the basic invlrng using invlpg. > Unfortunately, I'm out of time for tonight. Hopefully the list > will have some great suggestions/fixes/improvements for this patch > before I pick it up again tomorrow. > > Thanks, > Justin ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen 4.2 PV fails to boot -CURRENT PV domU
On 09/09/13 11:19, Eggert, Lars wrote:
> Hi,
>
> I'm trying to run a recent-CURRENT XEN i386 kernel in a Xen 4.2 PV domU.
>
> I had to add the following options to the kernel config file in order to
> compile the XEN kernel:
>
> makeoptions WITHOUT_MODULES+="mlx4 mlx4ib mlxen mthca"
>
> The resulting kernel compiles, but fails to boot. Attached is the log. Any
> ideas?
This is due to the unification of event channel implementations. I'm
attaching a patch that should fix the issue (at least when using only
one vcpu).
The i386 Xen PV port doesn't fill the data in struct pcpu, so we end up
with uninitialised values there which are required for the new event
channel implementation. Maybe someone with more knowledge of the Xen
i386 PV port can provide a better solution.
If you plan to use the i386 PV port you will also need to revert r244237
in order for it to work.
May I ask if there's anything that prevents you from switching to the
PVHVM port? I wouldn't recommend using the i386 PV port.
Roger.
>From 0429a1ba5bdbca844e9a798df13396e1ee11aae0 Mon Sep 17 00:00:00 2001
From: Roger Pau Monne
Date: Mon, 9 Sep 2013 11:53:15 +0200
Subject: [PATCH] xen: set acpi_id for i386 PV port
Set a 'fake' acpi_id for the i386 PV port, it is needed in order to
use VIRQs or IPI event channels.
---
sys/i386/xen/mp_machdep.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/sys/i386/xen/mp_machdep.c b/sys/i386/xen/mp_machdep.c
index 274598f..4e4c07d 100644
--- a/sys/i386/xen/mp_machdep.c
+++ b/sys/i386/xen/mp_machdep.c
@@ -251,6 +251,9 @@ cpu_add(u_int apic_id, char boot_cpu)
if (bootverbose)
printf("SMP: Added CPU %d (%s)\n", apic_id, boot_cpu ? "BSP" :
"AP");
+
+ /* Set the ACPI id (it is needed by VCPU operations) */
+ pcpu_find(apic_id)->pc_acpi_id = apic_id;
}
void
--
1.7.7.5 (Apple Git-26)
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen 4.2 PV fails to boot -CURRENT PV domU
On 09/09/13 14:06, Eggert, Lars wrote: > Hi, > > thanks, let me try your suggestion/patch. > > On Sep 9, 2013, at 13:53, Roger Pau Monné wrote: >> May I ask if there's anything that prevents you from switching to the >> PVHVM port? I wouldn't recommend using the i386 PV port. > > I was thinking that performance would be better, and resource requirements > lower. If that's not the case, I can certainly go the PVHVM route. Performance will probably be better on most workloads with PVHVM if you have HAP (Intel's Extended Page Table or AMD's Nested Page Tables). And also, i386 PV port is limited to only one vcpu, while PVHVM will allow you to use as many vcpus as you want. PVHVM certainly has a higher resource requirement because it requires you to have a Qemu instance for each running VM, but that process is going to be idle most of the time (Qemu is mainly needed for booting). Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen 4.2 PV fails to boot -CURRENT PV domU
On 09/09/13 15:13, Eggert, Lars wrote: > Hi, > > On Sep 9, 2013, at 14:06, "Eggert, Lars" > wrote: >> thanks, let me try your suggestion/patch. > > I applied the patch and tried booting. That failed (as expected) with a "bad > pte" panic: > > ... > Trying to mount root from ufs:/dev/ada0s1a []... > start_init: trying /sbin/init > dumpon: /dev/da1s1a: No such file or directory > pid 40 (sh), uid 0: exited on signal 11 > TPTE at 0xbf840258 IS ZERO @ VA 0804b000 > panic: bad pte > cpuid = 0 > KDB: enter: panic > [ thread pid 40 tid 100032 ] > Stopped at kdb_enter+0x3d: movl$0,kdb_why > > I then reverted r244237. The domU now boots a bit further, but there still > seem to be significant issues. Below is the complete log. Applying the patch I've sent and reverting r244237 seems to be enough for me, I can get the guest to boot fine. This is the cmdline that I use for booting: boot_verbose=1,vfs.root.mountfrom=ufs:/dev/xbd0p2,kern.hz=100,hw.mca.enabled=0 WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb APIC: Using the MPTable enumerator. SMP: Added CPU 0 (BSP) 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 #72 06b2ac0: Mon Sep 9 15:54:59 CEST 2013 root@:/usr/obj/usr/src/sys/XEN i386 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 3066.888 MHz processor. CPU: Intel(R) Xeon(R) CPU W3550 @ 3.07GHz (3066.89-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Family = 0x6 Model = 0x1a Stepping = 5 Features=0xbfe3fbff Features2=0x9ce3bd AMD Features=0x2810 AMD Features2=0x1 Data TLB: 4 KB pages, 4-way set associative, 64 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 256 kbytes, 8-way associative, 64 bytes/line real memory = 536870912 (512 MB) Physical memory chunk(s): 0x0085f000 - 0x1f6a0fff, 518266880 bytes (126530 pages) avail memory = 515629056 (491 MB) random device not loaded; using insecure entropy ULE: setup cpu 0 Event-channel device installed. null: nfslock: pseudo-device io: random: initialized mem: Pentium Pro MTRR support enabled xc0: on motherboard xenstore0: on motherboard Grant table initialized xen_et0: on motherboard Event timer "XENTIMER" frequency 10 Hz quality 950 Timecounter "XENTIMER" frequency 10 Hz quality 950 xen_et0: registered as a time-of-day clock (resolution 1000us, adjustment 5.0s) Device configuration finished. procfs registered Timecounters tick every 10.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 4096 lo0: bpf attached xctrl0: on xenstore0 xenbusb_front0: on xenstore0 xenbusb_add_device: Device device/suspend/event-channel ignored. State 6 xn0: at device/vif/0 on xenbusb_front0 xn0: bpf attached xn0: Ethernet address: 00:16:3e:47:d4:52 xenbusb_back0: on xenstore0 xn0: backend features: feature-sg feature-gso-tcp4 xbd0: 20480MB at device/vbd/51712 on xenbusb_front0 xbd0: features: flush, write_barrier xbd0: synchronize cache commands enabled. GEOM: new disk xbd0 TSC timecounter discards lower 1 bit(s) Timecounter "TSC-low" frequency 1533444000 Hz quality 800 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/xbd0p2 []... WARNING: / was not properly dismounted WARNING: /: mount pending error: blocks 0 files 1 start_init: trying /sbin/init Setting hostuuid: ee840805-6f57-4031-b4b8-919d4ac8021a. Setting hostid: 0xf9f637d0. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_pointsha256: /kernel: No such file or directory kickstart. swapon: /dev/ad0p3: No such file or directory Starting file system checks: ** SU+J Recovering /dev/xbd0p2 ** Reading 33554432 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 17 journal records in 1024 bytes for 53.12% utilization ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. * FILE SYSTEM MARKED CLEAN * Mounting local file systems:. Writing entropy file:. xn0: link state changed to DOWN xn0: link state changed to UP Starting Network: lo0 xn0. lo0: flags=8049 metric 0 mtu 16384 options=63 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff00 nd6 options=21 xn0: flags=8843 metric 0 mtu 1500 options=503 ether 00:16:3e:47:d4:52 nd6 options=29 media: Ethernet manual status: active Starting devd. Starting dhclient. DHCPDISCOVER on xn0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 172.16.1.1 DHCPREQUEST o
Re: Latest current -CURRENT (rev 255904) panics with "device hyperv" on XenServer 6.2
On 27/09/13 08:16, Shanker Balan wrote:
> Helo,
>
> Now that XENHVM has been merged into the GENERIC kernel, I recompiled todays
> -CURRENT (rev 255904)
> and hit the following panic. It seeems to be HyperV related.
>
> GENERIC without "device hyperv" works properly. The hypervisor is XenServer
> 6.2.
>
> # HyperV drivers
> device hyperv # HyperV drivers
>
> Panic screenshots with backtrace at http://imgur.com/cZsDsKE&VCkh4VS
Hello,
This is because XenServer enables viridian by default when running HVM
guests. That makes Xen also announce itself as HyperV for compatibility
reasons, as a workaround you can try to disable viridian support (not
sure if this is possible on XenServer).
I'm attaching a patch that should solve the problem, Ccing the virt
mailing list and the persons that I think are involved in the HyperV
support for FreeBSD.
Roger.
diff --git a/sys/dev/hyperv/vmbus/hv_hv.c b/sys/dev/hyperv/vmbus/hv_hv.c
index e3f3ae0..64b10fb 100644
--- a/sys/dev/hyperv/vmbus/hv_hv.c
+++ b/sys/dev/hyperv/vmbus/hv_hv.c
@@ -88,6 +88,16 @@ hv_vmbus_query_hypervisor_presence(void)
{
u_int regs[4];
int hyper_v_detected = 0;
+
+ /*
+* The Xen Hypervisor also announces itself as HyperV when
+* viridian support is enabled, but we should only use Xen
+* in this case, so check for Xen first and disable HyperV
+* support if Xen is found.
+*/
+ if (vm_guest == VM_GUEST_XEN)
+ return 0;
+
do_cpuid(1, regs);
if (regs[2] & 0x8000) { /* if(a hypervisor is detected) */
/* make sure this really is Hyper-V */
diff --git a/sys/x86/xen/hvm.c b/sys/x86/xen/hvm.c
index 2286cf0..9539dd1 100644
--- a/sys/x86/xen/hvm.c
+++ b/sys/x86/xen/hvm.c
@@ -699,6 +699,7 @@ xen_hvm_init(enum xen_hvm_init_type init_type)
return;
setup_xen_features();
+ vm_guest = VM_GUEST_XEN;
break;
case XEN_HVM_INIT_RESUME:
if (error != 0)
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Latest current -CURRENT (rev 255904) panics with "device hyperv" on XenServer 6.2
On 27/09/13 16:59, Shanker Balan wrote: > Roger, > > Thank you very much for looking into the issue. > > Can I have a SVN version of the patch? "patch" does not seem to like > the diff (or maybe I am using it incorrectly) > > root@fxen1:/usr/src # patch -n < ~/xen_hyperv.patch > Hmm... I can't seem to find a patch in there anywhere. $ patch -p1 < /path/to/patch should work AFAIK, this is a git generated diff. If it still doesn't work applying it by hand shouldn't be that hard. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD Alpha5 amd64 - Citrix Xen 6.2 problem
On 09/10/13 08:18, Shanker Balan wrote: > On 08-Oct-2013, at 9:19 PM, Mark Felder wrote: > >> On Tue, Oct 8, 2013, at 9:45, Josias L.G wrote: >>> Problem with Citrix Xen 6.2 and install from ISO. The "solution" was >>> remove cd-rom drive from virtual machine. Not possible now with xen >>> default in GENERIC kernel. >>> Message error: >>> run_interrupt_driven_hooks - still waiting after 300 seconds for >>> xenbusb_nop_confighook_cb >>> panic: run_interrupt_driven_config_hooks: waited too long >>> >> >> I was going to test this soon... but you're right -- you probably can't >> install FreeBSD 10 from ISO on Citrix XenServer because of this bug. >> >> Can someone working on the xen bits test and maybe find a workaround? > > The "xenbusb_nop_confighook_cb" issue is the only issue which I am aware > of that prevents CloudStack/XenServer IaaS private clouds from offering > FreeBSD 10 as a supported OS template. The "vbd-destroy" workaround is not > possible as the ISO is attached to the VM instance during the installation. > > A "please pretty please" request to @citrix R&D for the hopefully last fix > to get FreeBSD 10 running on XenServer+CloudStack. > > The earlier HyperV related panic on XenServer has been fixed in ALPHA5. Hello, I've taken a look into this and I'm afraid there's no easy way to workaround it from FreeBSD. When Xen is detected all IDE devices are disconnected, and there's no fine grained way to only disable IDE disks and not cdrom devices. Could you please contact your XenServer representative, and/or submit this bug to xs-devel (xs-de...@lists.xenserver.org) mailing lists in order to get this fixed on XenServer. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD Alpha5 amd64 - Citrix Xen 6.2 problem
On 09/10/13 13:49, Mark Felder wrote: > On Wed, Oct 9, 2013, at 2:46, Roger Pau Monné wrote: >> On 09/10/13 08:18, Shanker Balan wrote: >>> On 08-Oct-2013, at 9:19 PM, Mark Felder wrote: >>> >>>> On Tue, Oct 8, 2013, at 9:45, Josias L.G wrote: >>>>> Problem with Citrix Xen 6.2 and install from ISO. The "solution" was >>>>> remove cd-rom drive from virtual machine. Not possible now with xen >>>>> default in GENERIC kernel. >>>>> Message error: >>>>> run_interrupt_driven_hooks - still waiting after 300 seconds for >>>>> xenbusb_nop_confighook_cb >>>>> panic: run_interrupt_driven_config_hooks: waited too long >>>>> >>>> >>>> I was going to test this soon... but you're right -- you probably can't >>>> install FreeBSD 10 from ISO on Citrix XenServer because of this bug. >>>> >>>> Can someone working on the xen bits test and maybe find a workaround? >>> >>> The "xenbusb_nop_confighook_cb" issue is the only issue which I am aware >>> of that prevents CloudStack/XenServer IaaS private clouds from offering >>> FreeBSD 10 as a supported OS template. The "vbd-destroy" workaround is not >>> possible as the ISO is attached to the VM instance during the installation. >>> >>> A "please pretty please" request to @citrix R&D for the hopefully last fix >>> to get FreeBSD 10 running on XenServer+CloudStack. >>> >>> The earlier HyperV related panic on XenServer has been fixed in ALPHA5. >> >> Hello, >> >> I've taken a look into this and I'm afraid there's no easy way to >> workaround it from FreeBSD. When Xen is detected all IDE devices are >> disconnected, and there's no fine grained way to only disable IDE disks >> and not cdrom devices. >> >> Could you please contact your XenServer representative, and/or submit >> this bug to xs-devel (xs-de...@lists.xenserver.org) mailing lists in >> order to get this fixed on XenServer. >> > > Citrix is aware of this as I've contacted several people there and this > has been discussed both here and on the xs-devel list. There has to be > something FreeBSD can do to work around this issue since Linux and > NetBSD have no issues. Linux and NetBSD have no issues because you probably only tried them on PV mode, which doesn't exhibit this issue (also NetBSD doesn't have PVHVM support, so it's quite clear it won't have this issue). > As far as I'm aware the issue has been tracked > down to badly behaving qemu in XenServer -- they don't use upstream qemu > in XenServer (yet), and instead have their own fork. A future release is > supposed to merge with upstream qemu. The main problem here is that XenServer announces a PV block device on xenstore (the cdrom), but then it seems like there's no backend to handle it, so it hangs on the connection phase. IMHO the problem is not with the device model (Qemu), but with the backend that should handle this PV device. Xen only allows you to either disable all IDE devices or none, so the only possible solution I can think of is to not disable anything at all and use the emulated devices, which will leave us with very poor performance (unless I'm missing something, there's no way to only disable disks but not cdroms). > But the fact remains that this is a non-issue on Linux and NetBSD who > handle this buggy virtual CDROM without any problems. There has to be > some way we can add a quirk on our side so this device doesn't stop the > entire boot process. If FreeBSD 10 is released without out-of-the-box > support on the premier commercial Xen platform we'll be shooting > ourselves in the foot and all of this work will be for naught. Amazon > isn't the only Xen platform people use. You can always use the pre-build VM images I guess (I have not tested those, but I expect they should work fine under Xen). ftp://ftp.nl.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/20131007/10.0-ALPHA5/amd64/ ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
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é 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-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD Alpha5 amd64 - Citrix Xen 6.2 problem
On 14/10/13 15:57, Mark Felder wrote: > Patching 9-STABLE with this applies cleanly, but I'm guessing the work > done with the restructuring so it fits in GENERIC is not permitting it > to build. > > > /usr/src/sys/dev/xen/blkfront/blkfront.c: In function 'blkfront_probe': > /usr/src/sys/dev/xen/blkfront/blkfront.c:405: warning: implicit > declaration of function 'xen_hvm_domain' > /usr/src/sys/dev/xen/blkfront/blkfront.c:405: warning: nested extern > declaration of 'xen_hvm_domain' [-Wnested-externs] > *** [blkfront.o] Error code 1 > > Stop in /usr/obj/usr/src/sys/XENHVM. > *** [buildkernel] Error code 1 > > Stop in /usr/src. > *** [buildkernel] Error code 1 > > Stop in /usr/src. Yes, the xen_hvm_domain function is not available in 9-STABLE, you should be able to replace the 'if' gate with a '#ifdef XENHVM .. #endif' (not pretty, but should do it's job). Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: kern/171118: [xen] FreeBSD XENHVM guest doesn't shutdown cleanly
The following reply was made to PR kern/171118; it has been noted by GNATS.
From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?=
To: ,
Cc:
Subject: Re: kern/171118: [xen] FreeBSD XENHVM guest doesn't shutdown
cleanly
Date: Mon, 21 Oct 2013 16:18:34 +0100
When using libxl the event sent is a "poweroff", but I guess XenServer
toolstack is sending a "halt" event instead (which libxl doesn't use
for anything). The following patch wires the "halt" event handler to
the "poweroff" handler and removes the now unused "halt" handler.
I'm currently on a trip, so I haven't been able to test the patch
(not even compile tested).
---
diff --git a/sys/dev/xen/control/control.c b/sys/dev/xen/control/control.c
index 35c923d..78894ba 100644
--- a/sys/dev/xen/control/control.c
+++ b/sys/dev/xen/control/control.c
@@ -158,7 +158,6 @@ static xctrl_shutdown_handler_t xctrl_poweroff;
static xctrl_shutdown_handler_t xctrl_reboot;
static xctrl_shutdown_handler_t xctrl_suspend;
static xctrl_shutdown_handler_t xctrl_crash;
-static xctrl_shutdown_handler_t xctrl_halt;
/*-- Private Data Structures
-*/
/** Element type for lookup table of event name to handler. */
@@ -173,7 +172,7 @@ static const struct xctrl_shutdown_reason
xctrl_shutdown_reasons[] = {
{ "reboot", xctrl_reboot },
{ "suspend", xctrl_suspend },
{ "crash",xctrl_crash},
- { "halt", xctrl_halt },
+ { "halt", xctrl_poweroff },
};
struct xctrl_softc {
@@ -427,12 +426,6 @@ xctrl_crash()
}
static void
-xctrl_halt()
-{
- shutdown_nice(RB_HALT);
-}
-
-static void
xen_pv_shutdown_final(void *arg, int howto)
{
/*
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Paravirt domU and PCI Passthrough
On 05/11/13 09:43, Hilton Day wrote: > Hi - firstly a warning. While I've been running Xen on Linux for about 6 > years, I've only just started to scratch the surface of freeBSD. > > I just compiled a (working) paravirt kernel for freeBSD 8.3 (actually for > pfSense firewall), and have succeeded in running it with a couple of > virtual interfaces. However, I've struck a couple of limitations: > > 1. Seems to be no support for the Xen pcifront to enable pci passthrough > to paravirt domUs? No, there's no pcifrontend, so right now it's not possible to use i386 PV guests with pci-passthrough. > 2. SMP support seems to be broken - I get a kernel panic with more than > one core for the VM. Yes, it's broken. > I've had a look and can't find anything like the Linux kernel option > for CONFIG_XEN_PCIDEV_FRONTEND > to enable pci support in paravirt? (but this could be lack of familiarity > with freeBSD build process/tree/files). > > I've succeessfully passed thorugh the same NIC to freeBSD Xen HVM domUs > (running 8.3 and 9.1), but would prefer to get a fully paravirt instance up > and running. > > Is PCI Passthrough possible with a freeBSD paravirt domU? I just set up a > freeBSD 10 BETA2 environment and have kicked off the build process with: > >> make buildkernel KERNCONF=XEN > > I'm just wondering whether I'm chasing a dead end and should just settle > for a XEN HVM solution? There have been a lot of improvements recently (that apply to both HEAD and stable-10) in order to get PVHVM working, which has a performance similar to pure PV (or even better depending on the workload). Also, i386 PV is currently broken on both HEAD and stable-10 AFAIK, so I would recommend switching to PVHVM instead. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Paravirt domU and PCI Passthrough
On 07/11/13 12:27, Roger Pau Monné wrote: > On 05/11/13 09:43, Hilton Day wrote: >> Hi - firstly a warning. While I've been running Xen on Linux for about 6 >> years, I've only just started to scratch the surface of freeBSD. >> >> I just compiled a (working) paravirt kernel for freeBSD 8.3 (actually for >> pfSense firewall), and have succeeded in running it with a couple of >> virtual interfaces. However, I've struck a couple of limitations: >> >> 1. Seems to be no support for the Xen pcifront to enable pci passthrough >> to paravirt domUs? > > No, there's no pcifrontend, so right now it's not possible to use i386 > PV guests with pci-passthrough. This is not completely true, there's a pcifront driver, but it's not included in the i386 PV build (and it seems like it never was included), so my guess is that it is probably broken or incomplete. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVH guest support
On 07/11/13 19:10, Roger Pau Monné wrote: > On 28/10/13 14:35, Roger Pau Monné wrote: >> Hello, >> >> The Xen community is working on a new virtualization mode (or maybe I >> should say an extension of HVM) to be able to run PV guests inside HVM >> containers without requiring a device-model (Qemu). One of the >> advantages of this new virtualization mode is that now it is much more >> easier to port guests to run under it (as compared to pure PV guests). >> >> Given that FreeBSD already supports PVHVM, adding PVH support is quite >> easy, we only need some glue for the PV entry point and then support >> for diverging some early init functions (like fetching the e820 map or >> starting the APs). >> >> The attached patch contains all this changes, and allows a SMP FreeBSD >> guest to fully boot (and AFAIK work) under this new PVH mode. The patch >> can also be found on my git repo: >> >> git://xenbits.xen.org/people/royger/freebsd.git pvh_v2 >> >> The patch touches quite a lot of the early init, so I've Cced the >> persons that maintain those areas, so they can review it. >> >> In order to test it, and since the PVH changes are not yet merged into >> upstream Xen, the use of a patched Xen is necessary. I've collected the >> patches for PVH guest support from George Dunlap (v13) and fixed some >> bugs on top of them, the tree can be found at: >> >> git://xenbits.xen.org/people/royger/xen.git fix_pvh > > I've updated the patch (as suggested by John Baldwin) and added a Xen > Nexus, that attaches all the Xen top-level devices, this gets rid of the > legacy bus. > > The new patch can be found at: > > git://xenbits.xen.org/people/royger/freebsd.git pvh_v2 The correct branch is pvh_v3, not pvh_v2: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v3 ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVH guest support
Hello, I've updated the branch one more time in order to cope with the recent HEAD changes regarding SMAP parsing, as usual the branch can be found at: http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v5 Also, I've created a wiki page that describes how to set up a FreeBSD PVH guest: http://wiki.xen.org/wiki/FreeBSD_PVH In case anyone wants to give it a try :) Thanks. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen Guests / NTP best practice?
On 29/11/13 16:23, Karl Pielorz wrote: > > Hi, > > We have a number of FreeBSD 9.x boxes now running under XenServer 6.2 > > Does anyone have any info / best practice / guides for what's best to > use NTP / time sync wise? > > I've noticed that NTP isn't "overly happy" on some of these hosts (i.e. > it doesn't seem to settle on some, or will run for a while - then de-sync). > > We have two local NTP servers (not virtualized) - should we be getting > the guest to sync? - Can Xen keep the clock in sync for us (Xen itself > is pointed at the two ntp servers) - or are there any options / configs > we should consider using with NTP to keep time sync'd up? There have been some improvements in 10 regarding timekeeping, now FreeBSD makes use of the PV timer and PV clock when running under HVM, which should be more stable. Could you try if your issues with ntp are reproducible on 10? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen Guests / NTP best practice?
On 30/11/13 11:52, Karl Pielorz wrote: > > > --On 29 November 2013 18:43:32 +0100 Roger Pau Monné > wrote: > >> There have been some improvements in 10 regarding timekeeping, now >> FreeBSD makes use of the PV timer and PV clock when running under HVM, >> which should be more stable. >> >> Could you try if your issues with ntp are reproducible on 10? > > Sure, I'll give 10 a go. Does the above mean for a VM you don't need to > run ntp? (i.e. it'll stay in sync with dom0 / the XenServer?) - or is > ntp still necessary? Well, if the Dom0 is keep in sync, the DomU clock should also be in sync, but I'm not sure how often does FreeBSD poll the underlying clock, so I would recommend running ntp even in that case (certainly it's not going to hurt). > Likewise do you know if there is any recommended solution for 9.x (which > is the bulk of our VM's). Apart from ntp/ntpdate, I cannot think of anything else. Backporting the changes from 10 is certainly not going to be easy. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVH guest support
Hello, I've yet updated the PVH work one more time, regarding some comments from emaste in order to try to make this work easier to merge with the UEFI changes. In this regard, the parse_memmap hook now fetches and parses the memmap, so UEFI can define it's own hook and do the fetching and parsing there. As usual, the patch can be found on my git tree: git://xenbits.xen.org/people/royger/freebsd.git pvh_v6 Or http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v6 I would really like to get this committed sooner rather than later, mainly because I plan to start working on Dom0 soon, and having to carry another patch on top of this is going to be quite hard. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD PVH guest support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/12/13 18:19, Konstantin Belousov wrote: > On Mon, Dec 02, 2013 at 05:11:49PM +0100, Roger Pau Monn? wrote: >> Hello, >> >> I've yet updated the PVH work one more time, regarding some >> comments from emaste in order to try to make this work easier to >> merge with the UEFI changes. In this regard, the parse_memmap >> hook now fetches and parses the memmap, so UEFI can define it's >> own hook and do the fetching and parsing there. >> >> As usual, the patch can be found on my git tree: >> >> git://xenbits.xen.org/people/royger/freebsd.git pvh_v6 >> >> Or >> >> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=shortlog;h=refs/heads/pvh_v6 >> >> >> I would really like to get this committed sooner rather than later, >> mainly because I plan to start working on Dom0 soon, and having >> to carry another patch on top of this is going to be quite hard. > > The patch is large, and I definitely do not have desire to look at > the Xen-specific parts. Is it possible to split the patch into > changes for common code, and the rest ? If not, could you provide > only the chunks related to the common code anyway, so that I read > what needed to read, and do not miss some part ? You can certainly use http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=commit;h=e6b5f404ea805de4070a9ad501be8e91a722f05b in order to see the specific diffs for each modified file, this way you can only look at changes in common files and skip most of the Xen specific changes. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iQEcBAEBAgAGBQJSnMofAAoJEKXZdqUyumTAzjUH/3fDf9TDgBbKJoOlgPGWhTc3 GDY9Vw2oRzfB7IAyNKGXesE5PPkl4S2A/VVxN/So9Jw1PdGwK/iUGNQIyR5jI5YW BOclDB42huRoHRPYXH/pDrdHpOKrudJg9GeXldT0Q+EXThDMKgTGuAekqdtSN6dS F8YtXMokMrIBkklCzTBsJLAhA8nAZ+CozLuIgHUelkY5XX8Zw7RhrAZNZWy6WZP5 nGgVL6eeJ1mQ6l8JLSwEAvo6mx7ka7HVLmx4IQ1Plm6nx17WLIUdJi9NI6tW7s5v LAD6BH+iPCxDOK6qDCVmSHAZ6RJmI+ksasqIRx4pAe02l806qAUsoXjyzymgn6Y= =ovkV -END PGP SIGNATURE- ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD 10-BETA4 r258899 PVHVM Xen clock -> 1970 on VM migration
On 06/12/13 18:14, Adam McDougall wrote: > Hello, > > I noticed on recent (PVHVM) builds of FreeBSD 10 that I randomly lose the > proper date/time when I migrate my VM from one XenServer to another in the > pool. I was intending to reproduce a much smaller time difference I've seen > on 9 but this was a much bigger jump so I started concentrating on the big > jumps. When I migrate my VM back and forth between two servers, it will > randomly jump to a date in 1970 or 1969. Continued migrations often bring > the proper date/time back, but there is not a strong pattern. The 1970 > comes and goes. I could not reproduce this kind of jump on 9. This happens > on XenServer 6.0 and 6.2. Hello, Thanks for testing, there were some bugs in Xen regarding the migration of PVHVM guests, the one that comes to mind, and that could cause this kind of time disruption is: http://lists.xenproject.org/archives/html/xen-devel/2013-06/msg01110.html The patch should be present in at least Xen 4.3, not sure about previous versions. Is there anyway you could try this on a recent Xen version (4.3)? > I will take a stab at trying PVH time permitting, > but since 10.0 will ship with PVHVM it seems appropriate to try to fix it > if possible. Let me know if there is more testing or information gathering > I should do. Thanks. Xen 4.4 will be the first version to support PVH, which has not yet been released, and right now doesn't support migration. If you could try a recent version of Xen that contains the mentioned patch it will certainly help diagnose it (or at least make sure it's caused by this issue). Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
[HEADS UP] FreeBSD guest integrated into Xen push gate tests
Hello, Today we had the first successful run of the Xen push gate tester (OSSTest) containing a FreeBSD PVHVM guest. This means that from now onwards every commit on the Xen repository will be tested against a FreeBSD PVHVM guest (i386 and amd64), to make sure new changes in Xen doesn't break current support in FreeBSD. You can see the results of the first run at: http://www.chiark.greenend.org.uk/~xensrcts/logs/22323/ The jobs are test-amd64-i386-freebsd10-amd64 and test-amd64-i386-freebsd10-i386, you can see what's being tested on the results matrix. This guests are created using the official FreeBSD VM images, found at: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA3/ Right now it's using the BETA3 images, but I plan to update that once 10.0 is released. A very big thanks goes to Ian Jackson for integrating my crappy FreeBSD install script into OSSTest and for solving the various problems that arose during the integration. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: XEN vs XENHVM?
On 14/12/13 03:28, Colin Percival wrote: > On 12/13/13 18:23, Mason Loring Bliss wrote: >> I was psyched to see that GENERIC kernels in 10 have HVMXEN support by >> default, but then I was left a little confused. >> >> What's the different between a kernel with options XEN and one with options >> HVMXEN? > > The XEN option is for *paravirtualized* Xen -- aka. the original version, > before Intel and AMD added virtualization support into their CPUs. HVM > uses "hardware virtualization", but we also use PV drivers where available. > >> I'd love to be able to run FreeBSD domU systems without having to do >> a custom compile whenever there's an update. I've got a 9.1 system running >> now, using a copy of the XEN config with a couple tweaks, and I see all the >> PV drivers I expect. I'm wondering what's different with XENHVM... Also >> useful would be knowing if there are remaining differences between i386 and >> amd64 as a domU in FreeBSD 10. > > You want to switch to using HVM with PV devices. That should be a simple > tweak to your Xen configuration, and then you'll be able to use a GENERIC > kernel. Just as a note, the support in GENERIC is not only HVM with PV devices, is basically a PV guest inside an HVM container, meaning it also uses PV IPIs and PV timers. The main difference between pure PV and PVHVM is that PV requires a PV MMU implementation in the OS, while PVHVM can use a hardware virtualized MMU (because it's running inside of a HVM container). Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Panic with FreeBSD 10 RC2 on Netbsd Xen dom0
On 19/12/13 02:38, Mike C. wrote: > I've reported this to xen-devel I while ago. > > > It worked in the first FreeBSD-10 current releases but them it stoped, I > believe a previous issue was re-introduced somehow! > > NetBSD Xen backend does not support TSO/GSO at all, there was a very > similar problem in FreeBSD 9 a while a go, and my guess is that the code > tried to use TSO again, and leads to problems if the Dom0 is NetBSD. > > > Also more recently I had problems with Windows GPLPV drivers, and the > dev tracked the issue to the same.. however in windows DomU's if I > disabled TSO it would work. > In FreeBSD at least until Aplha 5, I tried to disable TSO but it still > wouldn't work. By looking at relevant commits in netfront, could you try to revert r251297 and see if that solves the problem? Also, doing a bisect of the commits in netfront would be very helpful in order to identify the issue. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v7 04/19] amd64: introduce hook for custom preload metadata parsers
On 24/12/13 16:47, John Baldwin wrote: > On Thursday, December 19, 2013 1:54:41 pm Roger Pau Monne wrote: >> --- /dev/null >> +++ b/sys/xen/pv.h >> @@ -0,0 +1,28 @@ >> +/* >> + * Permission is hereby granted, free of charge, to any person obtaining a >> copy >> + * of this software and associated documentation files (the "Software"), to >> + * deal in the Software without restriction, including without limitation >> the >> + * rights to use, copy, modify, merge, publish, distribute, sublicense, >> and/or >> + * sell copies of the Software, and to permit persons to whom the Software >> is >> + * furnished to do so, subject to the following conditions: >> + * >> + * The above copyright notice and this permission notice shall be included >> in >> + * all copies or substantial portions of the Software. >> + * >> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS >> OR >> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, >> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL >> THE >> + * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER >> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING >> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER >> + * DEALINGS IN THE SOFTWARE. > > One non-technical question. This license statement doesn't actually say who > the > copyright belongs to which seems problematic. Would it be possible to use > FreeBSD's > preferred 2-clause BSD license on this file? I copied the license from sys/xen/hvm.h without realizing it was not the standard 2-clause BSD one, but I don't have any problem changing it (maybe we should also change hvm.h?) to match the license in pv.c. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v9 19/19] isa: allow ISA bus to attach to xenpv device
On 03/01/14 01:22, Julian Elischer wrote: > On 1/2/14, 4:43 PM, Roger Pau Monne wrote: >> --- >> sys/x86/isa/isa.c |3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/sys/x86/isa/isa.c b/sys/x86/isa/isa.c >> index 1a57137..9287ff2 100644 >> --- a/sys/x86/isa/isa.c >> +++ b/sys/x86/isa/isa.c >> @@ -241,3 +241,6 @@ isa_release_resource(device_t bus, device_t child, >> int type, int rid, >>* On this platform, isa can also attach to the legacy bus. >>*/ >> DRIVER_MODULE(isa, legacy, isa_driver, isa_devclass, 0, 0); >> +#ifdef XENHVM >> +DRIVER_MODULE(isa, xenpv, isa_driver, isa_devclass, 0, 0); >> +#endif > read all 19 patches. I'm glad you split them up.. makes it > understandable.. even by me :-) > no real negative comments except a question as to whether there is any > noticable performance impact on real hardware? Thanks for taking a look. I haven't seen any performance impact when running a PVH capable kernel (a kernel with this patch series applied) on real hardware. I'm not adding hooks to any hot paths, most of the code added in this series is only used during boot time. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
On 05/01/14 22:55, Julien Grall wrote: > > > On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >> Introduce a Xen specific nexus that is going to be in charge for >> attaching Xen specific devices. > > Now that we have a xenpv bus, do we really need a specific nexus for Xen? > We should be able to use the identify callback of xenpv to create the bus. > > The other part of this patch can be merged in the patch #14 "Introduce > xenpv bus and a dummy pvcpu device". On x86 at least we need the Xen specific nexus, or we will fall back to use the legacy nexus which is not what we really want. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] [PATCH v9 14/19] xen: introduce xenpv bus and a dummy pvcpu device
On 05/01/14 22:52, Julien Grall wrote:
>
>
> On 01/02/2014 03:43 PM, Roger Pau Monne wrote:
>> Since Xen PVH guests doesn't have ACPI, we need to create a dummy
>> bus so top level Xen devices can attach to it (instead of
>> attaching directly to the nexus) and a pvcpu device that will be used
>> to fill the pcpu->pc_device field.
>> ---
>> sys/conf/files.amd64 |1 +
>> sys/conf/files.i386 |1 +
>> sys/x86/xen/xenpv.c | 155
>> ++
>
> I think it makes more sense to have 2 files: one for xenpv bus and one
> for a dummy pvcpu device. It would allow us to move xenpv bus to common
> code (sys/xen or sys/dev/xen).
Ack. I wasn't thinking other arches will probably use the xenpv bus but
not the dummy cpu device. Would you agree to leave xenpv bus inside
x86/xen for now and move the dummy PV cpu device to dev/xen/pvcpu/?
>
> [..]
>
>> +
>> +static int
>> +xenpv_probe(device_t dev)
>> +{
>> +
>> +device_set_desc(dev, "Xen PV bus");
>> +device_quiet(dev);
>> +return (0);
>
> As I understand, 0 means I can "handle" the current device, in this case
> if a device is probing, because it doesn't have yet a driver, we will
> use xenpv and end up with 2 (or even more) xenpv buses.
>
> As we only want to probe xenpv bus once, when the bus was added
> manually, returning BUS_PROBE_NO_WILDCARD would suit better.
>
> [..]
>
>> +static int
>> +xenpvcpu_probe(device_t dev)
>> +{
>> +
>> +device_set_desc(dev, "Xen PV CPU");
>> +return (0);
>
> Same here: BUS_PROBE_NOWILDCARD.
Ack for both, will change it to BUS_PROBE_NOWILDCARD. While at it, we
should also change xenstore probe function to return BUS_PROBE_NOWILDCARD.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Panic with FreeBSD 10 RC2 on Netbsd Xen dom0
On 19/12/13 09:19, Roger Pau Monné wrote: > On 19/12/13 02:38, Mike C. wrote: >> I've reported this to xen-devel I while ago. >> >> >> It worked in the first FreeBSD-10 current releases but them it stoped, I >> believe a previous issue was re-introduced somehow! >> >> NetBSD Xen backend does not support TSO/GSO at all, there was a very >> similar problem in FreeBSD 9 a while a go, and my guess is that the code >> tried to use TSO again, and leads to problems if the Dom0 is NetBSD. >> >> >> Also more recently I had problems with Windows GPLPV drivers, and the >> dev tracked the issue to the same.. however in windows DomU's if I >> disabled TSO it would work. >> In FreeBSD at least until Aplha 5, I tried to disable TSO but it still >> wouldn't work. > > By looking at relevant commits in netfront, could you try to revert > r251297 and see if that solves the problem? Also, doing a bisect of the > commits in netfront would be very helpful in order to identify the issue. Ping? Any news on this? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] [PATCH v9 14/19] xen: introduce xenpv bus and a dummy pvcpu device
On 06/01/14 12:28, Julien Grall wrote:
>
>
> On 01/06/2014 09:46 AM, Roger Pau Monné wrote:
>> On 05/01/14 22:52, Julien Grall wrote:
>>>
>>>
>>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote:
>>>> Since Xen PVH guests doesn't have ACPI, we need to create a dummy
>>>> bus so top level Xen devices can attach to it (instead of
>>>> attaching directly to the nexus) and a pvcpu device that will be used
>>>> to fill the pcpu->pc_device field.
>>>> ---
>>>>sys/conf/files.amd64 |1 +
>>>>sys/conf/files.i386 |1 +
>>>>sys/x86/xen/xenpv.c | 155
>>>> ++
>>>
>>> I think it makes more sense to have 2 files: one for xenpv bus and one
>>> for a dummy pvcpu device. It would allow us to move xenpv bus to common
>>> code (sys/xen or sys/dev/xen).
>>
>> Ack. I wasn't thinking other arches will probably use the xenpv bus but
>> not the dummy cpu device. Would you agree to leave xenpv bus inside
>> x86/xen for now and move the dummy PV cpu device to dev/xen/pvcpu/?
>
> As we will attach every xen device to xenpv, it makes more sense to have
> xenpv bus used on ARM. It will avoid duplication code and keep it nicer.
>
> I'm fine with this solution for now. I will update/move the code when I
> will send the patch series to support FreeBSD on Xen on ARM.
>
>>>
>>> [..]
>>>
>>>> +
>>>> +static int
>>>> +xenpv_probe(device_t dev)
>>>> +{
>>>> +
>>>> +device_set_desc(dev, "Xen PV bus");
>>>> +device_quiet(dev);
>>>> +return (0);
>>>
>>> As I understand, 0 means I can "handle" the current device, in this case
>>> if a device is probing, because it doesn't have yet a driver, we will
>>> use xenpv and end up with 2 (or even more) xenpv buses.
>>>
>>> As we only want to probe xenpv bus once, when the bus was added
>>> manually, returning BUS_PROBE_NO_WILDCARD would suit better.
>>>
>>> [..]
>>>
>>>> +static int
>>>> +xenpvcpu_probe(device_t dev)
>>>> +{
>>>> +
>>>> +device_set_desc(dev, "Xen PV CPU");
>>>> +return (0);
>>>
>>> Same here: BUS_PROBE_NOWILDCARD.
>>
>> Ack for both, will change it to BUS_PROBE_NOWILDCARD. While at it, we
>> should also change xenstore probe function to return
>> BUS_PROBE_NOWILDCARD.
>>
>
> Right, I have a patch for xenstore. Do you want me to send it?
Sure, send it!
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
On 06/01/14 12:33, Julien Grall wrote: > > > On 01/06/2014 09:35 AM, Roger Pau Monné wrote: >> On 05/01/14 22:55, Julien Grall wrote: >>> >>> >>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>>> Introduce a Xen specific nexus that is going to be in charge for >>>> attaching Xen specific devices. >>> >>> Now that we have a xenpv bus, do we really need a specific nexus for >>> Xen? >>> We should be able to use the identify callback of xenpv to create the >>> bus. >>> >>> The other part of this patch can be merged in the patch #14 "Introduce >>> xenpv bus and a dummy pvcpu device". >> >> On x86 at least we need the Xen specific nexus, or we will fall back to >> use the legacy nexus which is not what we really want. >> > > Oh right, in any case can we use the identify callback of xenpv to add > the bus? AFAICT this kind of bus devices don't have a identify routine, and they are usually added manually from the specific nexus, see acpi or legacy. Could you add the device on ARM when you detect that you are running as a Xen guest, or in the generic ARM nexus if Xen is detected? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] [PATCH v9 04/19] amd64: introduce hook for custom preload metadata parsers
On 03/01/14 21:59, Konrad Rzeszutek Wilk wrote:
> On Thu, Jan 02, 2014 at 04:43:38PM +0100, Roger Pau Monne wrote:
>> ---
>> sys/amd64/amd64/machdep.c | 41 --
>> sys/amd64/include/sysarch.h | 12 ++
>> sys/x86/xen/pv.c| 82
>> +++
>> 3 files changed, 124 insertions(+), 11 deletions(-)
>>
>> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c
>> index eae657b..e073eea 100644
>> --- a/sys/amd64/amd64/machdep.c
>> +++ b/sys/amd64/amd64/machdep.c
>> @@ -126,6 +126,7 @@ __FBSDID("$FreeBSD$");
>> #include
>> #include
>> #include
>> +#include
>> #ifdef PERFMON
>> #include
>> #endif
>> @@ -165,6 +166,14 @@ static int set_fpcontext(struct thread *td, const
>> mcontext_t *mcp,
>> char *xfpustate, size_t xfpustate_len);
>> SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL);
>>
>> +/* Preload data parse function */
>> +static caddr_t native_parse_preload_data(u_int64_t);
>> +
>> +/* Default init_ops implementation. */
>> +struct init_ops init_ops = {
>> +.parse_preload_data = native_parse_preload_data,
>
> Extra space there.
It's for alignment, looks strange now because there's only one hook.
>> +};
>> +
>> /*
>> * The file "conf/ldscript.amd64" defines the symbol "kernphys". Its value
>> is
>> * the physical address at which the kernel is loaded.
>> @@ -1683,6 +1692,26 @@ do_next:
>> msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);
>> }
>>
>> +static caddr_t
>> +native_parse_preload_data(u_int64_t modulep)
>> +{
>> +caddr_t kmdp;
>> +
>> +preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE);
>
> Two casts? Could it be done via one?
>
>> +preload_bootstrap_relocate(KERNBASE);
>> +kmdp = preload_search_by_type("elf kernel");
>> +if (kmdp == NULL)
>> +kmdp = preload_search_by_type("elf64 kernel");
>> +boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int);
>> +kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE;
>> +#ifdef DDB
>> +ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t);
>> +ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t);
>> +#endif
>> +
>> +return (kmdp);
>> +}
>> +
>> u_int64_t
>> hammer_time(u_int64_t modulep, u_int64_t physfree)
>> {
>> @@ -1707,17 +1736,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree)
>> */
>> proc_linkup0(&proc0, &thread0);
>>
>> -preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE);
>
> Oh, you just moved the code - right, lets not modify it in this patch.
Yes, it's just code movement.
>
>> -preload_bootstrap_relocate(KERNBASE);
>> -kmdp = preload_search_by_type("elf kernel");
>> -if (kmdp == NULL)
>> -kmdp = preload_search_by_type("elf64 kernel");
>> -boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int);
>> -kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE;
>> -#ifdef DDB
>> -ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t);
>> -ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t);
>> -#endif
>> +kmdp = init_ops.parse_preload_data(modulep);
>>
>> /* Init basic tunables, hz etc */
>> init_param1();
>> diff --git a/sys/amd64/include/sysarch.h b/sys/amd64/include/sysarch.h
>> index cd380d4..58ac8cd 100644
>> --- a/sys/amd64/include/sysarch.h
>> +++ b/sys/amd64/include/sysarch.h
>> @@ -4,3 +4,15 @@
>> /* $FreeBSD$ */
>>
>> #include
>> +
>> +/*
>> + * Struct containing pointers to init functions whose
>> + * implementation is run time selectable. Selection can be made,
>> + * for example, based on detection of a BIOS variant or
>> + * hypervisor environment.
>> + */
>> +struct init_ops {
>> +caddr_t (*parse_preload_data)(u_int64_t);
>> +};
>> +
>> +extern struct init_ops init_ops;
>> diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c
>> index db3b7a3..908b50b 100644
>> --- a/sys/x86/xen/pv.c
>> +++ b/sys/x86/xen/pv.c
>> @@ -46,6 +46,8 @@ __FBSDID("$FreeBSD$");
>> #include
>> #include
>>
>> +#include
>> +
>> #include
>> #include
>>
>> @@ -54,6 +56,36 @@ extern u_int64_t hammer_time(u_int64_t, u_int64_t);
>> /* Xen initial function */
>> extern u_int64_t hammer_time_xen(start_info_t *, u_int64_t);
>>
>> +/*--- Forward Declarations
>> ---*/
>> +static caddr_t xen_pv_parse_preload_data(u_int64_t);
>> +
>> +static void xen_pv_set_init_ops(void);
>> +
>> +/* Global Data
>> ---*/
>> +/* Xen init_ops implementation. */
>> +struct init_ops xen_init_ops = {
>> +.parse_preload_data = xen_pv_parse_preload_data,
>> +};
>> +
>> +static struct
>> +{
>> +const char *ev;
>> +int mask;
>> +} howto_names[] = {
>> +{"boot_askname",RB_ASKNAME},
>> +{"boot_single", RB_SINGLE},
>> +{"boot_nosync", RB_NOSYNC},
>> +{"boot_halt", RB_ASKNAME},
>> +{"boot
Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH
On 07/01/14 15:27, Julien Grall wrote: > On 01/07/2014 08:29 AM, Roger Pau Monné wrote: >> On 06/01/14 12:33, Julien Grall wrote: >>> >>> >>> On 01/06/2014 09:35 AM, Roger Pau Monné wrote: >>>> On 05/01/14 22:55, Julien Grall wrote: >>>>> >>>>> >>>>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>>>>> Introduce a Xen specific nexus that is going to be in charge for >>>>>> attaching Xen specific devices. >>>>> >>>>> Now that we have a xenpv bus, do we really need a specific nexus for >>>>> Xen? >>>>> We should be able to use the identify callback of xenpv to create the >>>>> bus. >>>>> >>>>> The other part of this patch can be merged in the patch #14 "Introduce >>>>> xenpv bus and a dummy pvcpu device". >>>> >>>> On x86 at least we need the Xen specific nexus, or we will fall back to >>>> use the legacy nexus which is not what we really want. >>>> >>> >>> Oh right, in any case can we use the identify callback of xenpv to add >>> the bus? >> >> AFAICT this kind of bus devices don't have a identify routine, and they >> are usually added manually from the specific nexus, see acpi or legacy. >> Could you add the device on ARM when you detect that you are running as >> a Xen guest, or in the generic ARM nexus if Xen is detected? > > Is there any reason to not add identify callback? If it's possible, I > would like to avoid as much as possible #ifdef XENHVM in ARM code. Maybe the x86 world is really different from the ARM world in how nexus works, but I rather prefer to have a #ifdef XENHVM and a BUS_ADD_CHILD that attaches the xenpv bus in the generic ARM nexus rather than having something that completely diverges from what buses usually do in FreeBSD. It's going to be much more difficult to track in case of bugs, and it's not what people expects, but that's just my opinion. I can certainly add the identify routine if there's an agreement that it's the best way to deal with it. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
On 14/01/14 16:41, Julien Grall wrote:
> On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
>> +static int
>> +xenpv_attach(device_t dev)
>> +{
>> +device_t child;
>> +
>> +if (xen_hvm_domain()) {
>> +device_t xenpci;
>> +devclass_t dc;
>> +
>> +/* Make sure xenpci has been attached */
>> +dc = devclass_find("xenpci");
>> +if (dc == NULL)
>> +panic("unable to find xenpci devclass");
>> +
>> +xenpci = devclass_get_device(dc, 0);
>> +if (xenpci == NULL)
>> +panic("unable to find xenpci device");
>> +
>> +if (!device_is_attached(xenpci))
>> +panic("trying to attach xenpv before xenpci");
>> +}
>
> Can you use the identify method to add the xenpci device?
I don't think so, xenpci is a pci device, it is detected and plugged by
the pci bus code.
> As I said earlier, I will reuse this code for ARM guest and this device
> is not used on this architecture.
You could move this chunk of code (the check for xenpci) to a static
inline function and make it a noop for ARM.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH v10 14/20] xen: introduce xenpv bus and a dummy pvcpu device
On 14/01/14 17:14, Julien Grall wrote:
> On 01/14/2014 04:08 PM, Roger Pau Monné wrote:
>> On 14/01/14 16:41, Julien Grall wrote:
>>> On 01/14/2014 02:59 PM, Roger Pau Monne wrote:
>>>> +static int
>>>> +xenpv_attach(device_t dev)
>>>> +{
>>>> + device_t child;
>>>> +
>>>> + if (xen_hvm_domain()) {
>>>> + device_t xenpci;
>>>> + devclass_t dc;
>>>> +
>>>> + /* Make sure xenpci has been attached */
>>>> + dc = devclass_find("xenpci");
>>>> + if (dc == NULL)
>>>> + panic("unable to find xenpci devclass");
>>>> +
>>>> + xenpci = devclass_get_device(dc, 0);
>>>> + if (xenpci == NULL)
>>>> + panic("unable to find xenpci device");
>>>> +
>>>> + if (!device_is_attached(xenpci))
>>>> + panic("trying to attach xenpv before xenpci");
>>>> + }
>>>
>>> Can you use the identify method to add the xenpci device?
>>
>> I don't think so, xenpci is a pci device, it is detected and plugged by
>> the pci bus code.
>
> Oups, I though you are trying to add the device. In this case, the check
> seems pointless. In which case the xenpci couldn't exist?
It's just a "belt and suspenders", if we attach the xenpv bus without
xenpci being attached first a bunch of things are going to fail, I
though it might be best to print a clear error message about what went
wrong in order to help debug it.
___
freebsd-xen@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen PV Networking issue - disable PV NIC in XENHVM FreeBSD?
On 08/02/14 16:03, Karl Pielorz wrote: > > Hi, > > I've got an 'issue' (more with Xen than FreeBSD) - the upshot is, I need > to disable the PV NIC (xn) from a VM running XENHVM kernel. > > Is this possible? - In an ideal world I'd like to keep the storage > drivers etc. - I just need to use the HVM 're' interface, not 'xn' > interface... > > For those who want to know what the issue is - we have a number of VM's > on 1 Xen machine (e.g. 'Xen1') all using PV drivers (Windows and FreeBSD > VM's). A FreeBSD VM is the 'default' gateway for the others - and it > doesn't work :( > > Packets are either going missing - or getting mangled. If you 'migrate' > one of those hosts to another Xen machine in the pool (e.g. Xen2) it works. > > If you migrate the default gateway VM over to the other Xen machine - > all the other VM's on the original XenServer suddenly work (i.e. can see > the outside world) - alternatively if you switch from PV drivers to HVM > drivers on the affected guests - everything works, regardless of whether > the VM's are on Xen1, Xen2 - or the same XenServer as the default > gateway VM. > > Only PV <-> PV shows the issue, and only when they're both hosted on the > same XenServer. > > Hence wondering about disabling the PV nic on the default gateway, > instead of having to do it on all the other VM's... That's quite weird... Do you see any messages in the Xen console (xl dmesg)? Can you boot with a hypervisor compiled with debug=y and see if there are any strange messages on the Xen console? Also, does replacing the FreeBSD gateway VM with a Linux PV VM solve the issue? (ie. just to check if Linux also shows this behaviour) Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Xen PV Networking issue - disable PV NIC in XENHVM FreeBSD?
On 11/02/14 17:33, Karl Pielorz wrote: > > > --On 10 February 2014 17:29 +0100 Roger Pau Monné > wrote: > >> That's quite weird... Do you see any messages in the Xen console (xl >> dmesg)? Can you boot with a hypervisor compiled with debug=y and see if >> there are any strange messages on the Xen console? > > Ok, no messages logged anywhere when this goes on - I'm running > XenServer 6.2 installed from the distribution ISO (w/SP1 applied) - I > don't know/think that's compiled with 'debug=y'? dmesg output for > XenServer coming up is 'unremarkable' as far as I can see, and nothing > is logged with 'xl dmesg' > >> Also, does replacing the FreeBSD gateway VM with a Linux PV VM solve the >> issue? (ie. just to check if Linux also shows this behaviour) > > Ok, that I could do - and just did. I used CentOS 6 - which booted in > 'Xen' aware mode (with Xen Virtual ethernet driver) - annoyingly that > works *fine* (i.e. no issues). > > So, > > Windows 7 PV <-> FreeBSD 9.x / 10.x PV = Fail (if on same XenServer host) > Windows 7 HVM <-> FreeBSD PV = Works > Windows 7 PV <-> Linux (CentOS 6) PV = Works Just to clarify, are you unable to reach a FreeBSD PV DomU from a Windows PV DomU on the same host, or are you unable to route traffic trough a FreeBSD PV DomU (on the same host)? (ie. can you ssh from the Windows PV DomU into the FreeBSD PV DomU?) > > So it looks like it might actually be a FreeBSD/Xen issue? Yes, it looks that way (dunno if netback might also be involved in this) > I just tried booting FreeBSD 10 without the Xen options in the kernel, > and it won't boot (it panics). > > Is there any way of booting 10.x in HVM mode (i.e. with no Xen PV > support) - or at least switching 'xn' for 're' as far as nic's go? I have to look into this, FreeBSD should not panic when trying to boot without XENHVM on a DomU. AFAIK there's no way to selectively enable/disable the usage of certain PV interfaces, but I certainly don't recommend switching to an emulated nic to do the routing. > Are there any 'offload' type features that can be disabled for 'xn' nics > in FreeBSD? You could try to disable the following: ifconfig xnX -rxcsum -txcsum -tso4 -lro Or a mix of those, I'm afraid I'm not that familiar with netfront/netback to provide any more hints. In the past there have been reports of TSO breaking on Xen PV interfaces, but AFAIK this should be fixed already. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [PATCH RFC 10/13] xen: add ACPI bus to xen_nexus when running as Dom0
On 08/02/14 22:50, John Baldwin wrote: > On Tuesday, December 24, 2013 12:20:59 PM Roger Pau Monne wrote: >> Also disable a couple of ACPI devices that are not usable under Dom0. > > Hmm, setting debug.acpi.disabled in this way is a bit hacky. It might > be fine however if there's no way for the user to set it before booting > the kernel (as opposed to haing the relevant drivers explicitly disable > themselves under Xen which I think would be cleaner, but would also > make your patch larger) Thanks for the review, the user can pass parameters to FreeBSD when booted as Dom0, I just find it uncomfortable to force the user into always setting something on the command line in order to boot. What do you mean with "haing the relevant drivers explicitly disable themselves under Xen"? Adding a gate on every one of those devices like "if (xen_pv_domain()) return (ENXIO);" in the identify/probe routine seems even worse. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD 10-R 8 vCPU panics at boot under XenServer (on 8 'core' CPU)
On 17/02/14 15:44, Karl Pielorz wrote: > > Hi, > > I've got a FreeBSD 10-R amd64 DomU guest I'm using under XenServer 6.2 > (SP1) - this was working fine (i.e. had been restarted many times - > while I look at things like HAST). > > I noticed the other day it was only set to use 4 vCPU's - so I increased > this to 8 (the machine has an 4 Core, 8 Thread Xeon 1230v3 in it - which > Xen see's as 8 CPU cores). > > However, it won't boot reliably now: > > " > ... > SMP: AP CPU #5 Launched > panic: can't schedule timer > cpuid = 0 > KDB: stack backtrace: > #0 0x808e7dd0 at kdb_backtrace+0x60 > #1 0x808af8b5 at panic+0x155 > #2 0x807a14dd at xentimer_et_start+0xed > #3 0x80d66d6d at loadtimer+0xfd > #4 0x80d657fd at handleevents+0x308 > #5 0x80d65fc8 at timercb+0x308 > #6 0x807a152d at xentimer_intr+0x4d > #7 0x80883e5b at intr_event_handle+0x9b > ... > " > > Less than 8 vCPU's seems to boot OK (e.g. 7) and 8 vCPU's has booted a > couple of times (out of 30+ reboots). I usually do most of my testing on a Xen W3550 (8-ways), with a 8 vCPU guest, and I've never seen this crash before. I've even booted a 12 vCPU guest on this 8-way system, and it was fine. How many guests are you running on this host, and how many vCPUs has each one assigned? > The system is running GENERIC with: > > options NO_ADAPTIVE_MUTEXES > options NO_ADAPTIVE_RWLOCKS > options NO_ADAPTIVE_SX > > In addition XenServer is set to pass through the bare machine's LSI and > two Intel NIC's (which it does - and are working, once FreeBSD is booted). I don't think those modifications have any effect on the timer, but could you try to recompile without the NO_ADAPTIE_* modifications and without any device pass-through? In order to provide more debug info, could you apply the following patch: http://xenbits.xen.org/people/royger/0001-xen-debug-Xen-PV-timer.patch It will expand the panic message a little bit. Also, after applying the patch you can manually edit sys/dev/xen/timer/timer.c and increase NUM_RETRIES to see if that solves the problem. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: [Xen-devel] [PATCH RFC 09/13] xen: change quality of the MADT ACPI enumerator
On 14/02/14 18:51, John Baldwin wrote: > On Thursday, February 13, 2014 8:49:24 pm Andrew Cooper wrote: >> On 08/02/2014 21:42, John Baldwin wrote: >>> On Tuesday, December 24, 2013 12:20:58 PM Roger Pau Monne wrote: Lower the quality of the MADT ACPI enumerator, so on Xen Dom0 we can force the usage of the Xen mptable enumerator even when ACPI is detected. >>> Hmm, so I think one question is why does the existing MADT parser >>> not work with the MADT table provided by Xen? This may very well >>> be correct, but if it's only a small change to make the existing >>> MADT parser work with Xen's MADT table, that route might be >>> preferable. >>> >> >> For dom0, the MADT seen is the system MADT, which does not bear any >> reality to dom0's topology. For PV domU, no MADT will be found. For >> HVM domU, the MADT seen ought to represent (virtual) reality. > > Hmm, the other changes suggested that you do want to use the I/O APIC > entries and interrupt overrides from the system MADT for dom0? Just > not the CPU entries. Is that correct? Yes, we need the interrupt entries in order to interact with the underlying hardware, but not the CPU entries/topology. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FreeBSD 10-R 8 vCPU panics at boot under XenServer (on 8 'core' CPU)
On 17/02/14 21:00, Karl Pielorz wrote: > > --On 17 February 2014 16:56:14 +0100 Roger Pau Monné > wrote: > >> In order to provide more debug info, could you apply the following patch: >> >> http://xenbits.xen.org/people/royger/0001-xen-debug-Xen-PV-timer.patch >> >> It will expand the panic message a little bit. Also, after applying the >> patch you can manually edit sys/dev/xen/timer/timer.c and increase >> NUM_RETRIES to see if that solves the problem. > > Ok, tried adjusting the NUM_RETRIES #define in that patch (I left the > PCI passthroughs in place at the moment). I had no idea what to set it > to - so I went for 600. With it set at 600 that same guest now boots Ok > now every time I've tried. > > But I did notice the whole 'SMP AP CPU #x Launched!' takes forever, and > varies a lot (e.g. one boot it took nearly 2 minutes to launch all CPU's > and continue). > > I removed the PCI passthroughs on that guest, and it now flies through > the AP launches. Unfortunately though I need the passthroughs :( > > I've passed through the onboard LSI 2308 SAS controller (mps), and a > dual port PCI-E Intel NIC (igb) - all the passthroughs work on FreeBSD > once it's booted - but obviously, not without causing the slow AP CPU > launches. I've passed through a dual port BCE card (Broadcom NetXtreme II BCM5709) without problems. As a test, could you try to only pass the nic or the SAS controller to see if we can figure out if this is specific to one of the devices? > I also remembered I set 'hw.pci.enable_msi=1' and 'hw.pci.enable_msix=0' > in /etc/sysctl.conf - someone else found that was necessary to use the > LSI in passthrough mode. > > Aside from the slow launches, do you think (as they work) it's going to > cause issues leaving those passthroughs active? Not sure, still have to figure out what's going on. Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FBSD 10.0-S (r261289M) under XenServer 6.2 - Stuck sshd in urdlck?
On 17/03/14 17:59, Karl Pielorz wrote: > > Hi, > > I setup a VM a while ago under XenServer 6.2 - it's an amd64 FBSD 10.0-S > box (based on r261289) - it's running under Xen PVHVM. > > I set it up - and left it for a while (46 days). I went to ssh to it > today, and got: > > " > ssh_exchange_identification: Connection closed by remote host > " > > Getting on to the boxes console there's lots of what look to be 'stuck' > sshd processes? > > 0 3933 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: unknown > [priv] (sshd) > 22 3934 3933 0 20 0 00 - Z - 0:00.00 > 0 3935 3933 0 20 0 84868 6952 sbwait I - 0:00.00 sshd: unknown > [pam] (sshd) > 0 4338 895 0 20 0 84868 6944 urdlck Is - 0:00.01 sshd: unknown > [priv] (sshd) > 22 4339 4338 0 20 0 00 - Z - 0:00.00 > > > Anyone know what 'urdlck' is? It seems like the process is stuck while trying to acquire a rw mutex in read mode. Could you obtain a backtrace of the process with gdb? Also a kernel-space dump might be useful, could you also run procstat -k ? > > There's 126 of these processes, e.g. > > 5446 - I 0:00.00 sshd: unknown [pam] (sshd) > 5450 - Is0:00.01 sshd: unknown [priv] (sshd) > 5452 - I 0:00.00 sshd: unknown [pam] (sshd) > 5453 - Is0:00.01 sshd: unknown [priv] (sshd) > > > Bearing in mind the box is firewalled from ssh access, and no one (apart > from me today) has attempted to get onto the box with ssh - this is a > little concerning. Every about 5-10 connects will actually 'connect' - > the rest just result in the 'key exchange' error. > > Kernel is GENERIC with: > > options NO_ADAPTIVE_MUTEXES > options NO_ADAPTIVE_RWLOCKS > options NO_ADAPTIVE_SX > > There's nothing logged in dmesg, or syslog. > > Is there anything worth doing to this VM before I restart it - i.e. to > try and figure out what's happened? / troubleshoot? > > -Karl > > ___ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org" ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: FBSD 10.0-S (r261289M) under XenServer 6.2 - Stuck sshd in urdlck?
On 17/03/14 19:44, Karl Pielorz wrote: > > > --On 17 March 2014 18:17:53 +0100 Roger Pau Monné > wrote: > >>> Anyone know what 'urdlck' is? >> >> It seems like the process is stuck while trying to acquire a rw mutex in >> read mode. Could you obtain a backtrace of the process with gdb? > > Ok, I think I did this right - let me know if I've not... > > # gdb /usr/sbin/sshd 5325 > ... > Attaching to program: /usr/sbin/sshd, process 5325 > > warning: current_sos: Can't read pathname for load map: Bad address > [repeated several times] > [lots of reading symbols from - 'no debugging symbols found' output] > ... > [New Thread 804006400 (LWP 100184/sshd)] > [a few reading symbols - 'no debugging symbols found' output] > Loaded symbols for /libexec/ld-elf.so.1 > [Switching to Thread 804006400 (LWP 100184/sshd)] > 0x0008038eb89c in __error () from /lib/libthr.so.3 > (gdb) bt > #0 0x0008038eb89c in __error () from /lib/libthr.so.3 > #1 0x0008038e921c in pthread_timedjoin_np () from /lib/libthr.so.3 > #2 0x00080064f9a2 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 > #3 0x0008006498c9 in r_debug_state () from /libexec/ld-elf.so.1 > #4 0x0008006470cd in .text () from /libexec/ld-elf.so.1 > #5 0x0246 in ?? () > #6 0x in ?? () > " > >> Also a >> kernel-space dump might be useful, could you also run procstat -k ? > > procstat output is: > > " > # procstat -k 5334 > PIDTID COMM TDNAME KSTACK > 5334 100183 sshd -mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_rw_rdlock > __umtx_op_rw_rdlock amd64_syscall Xfast_syscall > " > > If you can briefly tell me how to do the kernel-space dump? Do I panic > the machine (i.e. cause a crash-dump?) somehow? The output of vmstat -ai might also be helpful to assure that event timers are working correctly. Also, does this VM have some PCI-passthrough? Did you migrate it? The xl configuration file used to create the domain would also be interesting. Also, could you try the same workload with a pristine GENERIC kernel? Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
Re: Terrible performance of XenServer 6.2 and FreeBSD 10.0-RELEASE guest
On 29/03/14 15:17, Big Lebowski wrote: > In addition to that, I've also noticed that even with xe guest utilitiest > installed and started, neither halt nor shutdown -h now are working (they > seem to stop the guest OS, but the vm stays up for the hypervisor and needs > to be forced to shutdown/restart) and that the XenCenter console is not > refreshing properly (it requires some additional movement, like cursor keys > being used to refresh the screen). I think you want `shutdown -p now`, which will poweroff the machine (-h just halts it). Roger. ___ freebsd-xen@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-xen To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"
