Re: CFT: replacing XENHVM kernel config with GENERIC + xenhvm.ko
On Mon, 2013-08-26 at 22:08 -0700, 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. ;-) The fine details: 1. I've created a new kernel module for i386 and amd64, xenhvm, with all of the source files which were added via options XENHVM and device xenpci. 2. I have removed those from sys/conf/files and sys/conf/options.*; those options are now meaningless. 3. I moved the detect Xen and disable QEMU emulated devices code from sys/amd64/amd64/machdep.c to the kernel module MOD_LOAD event handler. 4. I have made the PCPU values required by Xen/HVM support -- two unsigned ints -- unconditionally compiled in. This is the only change to the GENERIC kernel. 5. I have removed the XENHVM kernel configuration files. Depending on feedback from freebsd-xen@ I hope to send this to freebsd-current for wider review later this week and then commit it before the FreeBSD 10.0 code freeze starts on September 7th. Seems like you've got a winner there. $ uname -a FreeBSD ujvl 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r254959M: Tue Aug 27 18:29:11 EDT 2013 sbruno@ujvl:/usr/obj/usr/src/sys/GENERIC amd64 $ kldstat Id Refs AddressSize Name 1 21 0x8020 168eaa0 kernel 21 0x8188f000 76ef8xenhvm.ko 31 0x81a12000 34e0 ums.ko 41 0x81a16000 312c5pf.ko 51 0x81a48000 643d nullfs.ko 61 0x81a4f000 52c1 fdescfs.ko Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r254959M: Tue Aug 27 18:29:11 EDT 2013 sbruno@ujvl:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206c2 Family = 0x6 Model = 0x2c Stepping = 2 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x81b82201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,HV AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF real memory = 536870912 (512 MB) avail memory = 490692608 (467 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-47 on motherboard random: Software, Yarrow initialized kbd1 at kbdmux0 acpi0: Xen on motherboard acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) acpi0: reservation of 0, a (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 32-bit timer at 3.579545MHz port 0xb008-0xb00b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX3 WDMA2 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc1a0-0xc1af at device 1.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 uhci0: Intel 82371SB (PIIX3) USB controller port 0xc180-0xc19f irq 23 at device 1.2 on pci0 usbus0: controller did not stop usbus0 on uhci0 pci0: bridge at device 1.3 (no driver attached) vgapci0: VGA-compatible display mem 0xf000-0xf1ff,0xf304-0xf3040fff at device 2.0 on pci0 xenpci0: Xen Platform Device port 0xc000-0xc0ff mem 0xf200-0xf2ff irq 28 at device 3.0 on pci0 xenstore0: XenStore on xenpci0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: floppy drive controller port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
Re: XENHVM on -curent useless [VERY USEFUL TODAY]
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? Today, sync'd to head at svn r253159, head works *just fine* and is fantastic. :-) sean signature.asc Description: This is a digitally signed message part
XENHVM on -curent useless
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. For the record I did *try* to compile the PVHVM tree in git, and it did not build for me on 9.x because of some stupid unlreated yyparse error that made me table flip and go back to 9.1r Sean signature.asc Description: This is a digitally signed message part
Re: XENHVM on -curent useless
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. Sean p.s. thanks for your work on PVHVM. I look forward to testing it soon. signature.asc Description: This is a digitally signed message part
Re: PV crash
On Wed, 2013-06-26 at 13:40 +, Eggert, Lars wrote: real memory = 67108864 (64 MB) avail memory = 58556416 (55 MB) That looks a bit small for a x86 instance of FreeBSD 10 IMO. Try bumping that to 512MB just to be sure. Sean signature.asc Description: This is a digitally signed message part
Re: XENHVM ada - ad ?
On Fri, 2012-12-21 at 01:31 +0200, Ion-Mihai Tetcu wrote: Hi, I have the feeling I'm missing something very basic here: I have a 9-STABLE-amd64 (as of a few minutes ago, but I see the same thing with older versions) running as guest on Xen HVM (APIC, ACPI on). I can boot the GENERIC kernel, but trying to boot the XENHVM kernel results in trying to mount root from ufs: /dev/ada0p2 [rw] ... mountroot: waiting for device /dev/ada0p2 ... Mounting from ufs:/dev/ada0p2 failed with error 19. I can: mountroot ufs:ad0p2 and it breaks there, of course. Do I need to translate from 'ada' back to 'ad' if I use XENHVM? Why? Thanks, Yes. adaX--adX. Look at the dmesg on bootup. Sean ___ 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: Call for testers: vfork(2) repair for Xen
On Tue, 2012-12-04 at 23:02 +0200, Konstantin Belousov wrote:
Hi,
there is plain erronous special case for Xen in the handling of vfork(2)
syscall, which converts it into the fork(2), but only on Xen. I think this
was a bug to commit the change in the course of importing Xen support at all.
Could somebody of you, who use paravirtualized kernels, test the patch
below. After the patched kernel is booted, just running csh(1) and
calling any external command from it, e.g. ls(1), is enough.
I already tried to solicit the testing of the fix in private, but nobody
responded. I am going to commit the change in a week, unless somebody
report a real issue with Xen pmap, uncovered by it.
diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index b8a4825..0d2709f 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -150,11 +150,7 @@ sys_vfork(struct thread *td, struct vfork_args *uap)
int error, flags;
struct proc *p2;
-#ifdef XEN
- flags = RFFDG | RFPROC; /* validate that this is still an issue */
-#else
flags = RFFDG | RFPROC | RFPPWAIT | RFMEM;
-#endif
error = fork1(td, flags, 0, p2, NULL, 0);
if (error == 0) {
td-td_retval[0] = p2-p_pid;
Ack. Will test tonight after dom0.freebsd.org is restored.
Sean
___
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: xenbusb_nop_confighook_cb timeout and cd issue
On Mon, 2012-12-03 at 19:04 +0100, Egoitz Aurrekoetxea Aurre wrote:
Good morning,
After doing some checks and debugs about this problem, I can conclude that :
under Xen 4.1.3 on Debian Wheezy it works properly although in XCP1.6 if you
remove the cd drive from the vm works too. I'm going to describe the two test
environments have used for debugging this :
ENV 1.- XCP 1.6 XEN 4.1.3 + FREEBSD 9.1-RC3 :
As you can see with an iso image mounted and without it, the boot process
gets stuck there….. (I paste here both screenshot location).
http://postfixquotareject.ramattack.net/PastedGraphic-8.tiff
http://postfixquotareject.ramattack.net/PastedGraphic-11.tiff
I have placed here two examples, with an empty (but existing) cd drive and
with a iso mounted in the drive.
BUT If I do a in the XCP shell :
xe vm-cd-remove uuid=08aec342-9572-8690-5e58-91d1b1f0aab2 cd-name=xs-tools.iso
The drive is being removed from the vm and it boots normally. This is the
workaround I'm using for the moment.
Another debugging check I have done too is to apply this patch (although it's
just for testing purposes and for checking if cd drive works) to see how the
drive behaves after booting but without stopping in that loop of the FreeBSD
kernel source code.
--- /usr/src/sys/kern/subr_autoconf.c-defecto 2012-10-10 13:51:27.0
+0200
+++ /usr/src/sys/kern/subr_autoconf.c 2012-10-10 18:21:51.0 +0200
@@ -133,16 +133,17 @@
/* Block boot processing until all hooks are disestablished. */
mtx_lock(intr_config_hook_lock);
warned = 0;
- while (!TAILQ_EMPTY(intr_config_hook_list)) {
+ /* while (!TAILQ_EMPTY(intr_config_hook_list)) { */
if (msleep(intr_config_hook_list, intr_config_hook_lock,
0, conifhk, WARNING_INTERVAL_SECS * hz) ==
EWOULDBLOCK) {
mtx_unlock(intr_config_hook_lock);
warned++;
run_interrupt_driven_config_hooks_warning(warned);
mtx_lock(intr_config_hook_lock);
}
- }
+ /* } */
mtx_unlock(intr_config_hook_lock);
}
After applying this patch, kernel boots under XCP 1.6Beta and cd can be
mounted in the shell (should say I have not noticed about IRQ problems after
this). It seems like FreeBSD domU is not able to continue the boot process
because it's not able to finish up some test related to THIS (the cd drive)
device setup (IRQ assigning tests I assume concretely) that should succeed
before being able to continue the boot process.
ENV 2.- Debian Wheezy (testing) XEN 4.1.3 + FreeBSD 9.1-RC3 :
Here is the concrete environment and config :
root@pruebas-xen-egoitz:~# uname -ar
Linux pruebas-xen-egoitz 3.2.0-4-amd64 #1 SMP Debian 3.2.32-1 x86_64 GNU/Linux
root@pruebas-xen-egoitz:~# cat /etc/issue
Debian GNU/Linux wheezy/sid \n \l
root@pruebas-xen-egoitz:~# dpkg -l | grep -i xen
ii libxen-4.1 4.1.3-4 amd64
Public libs for Xen
ii libxenstore3.0 4.1.3-4 amd64
Xenstore communications library for Xen
ri linux-image-2.6.32-5-xen-amd64 2.6.32-46 amd64
Linux 2.6.32 for 64-bit PCs, Xen dom0 support
rc xen-hypervisor-4.0-amd64 4.0.1-5.4 amd64
The Xen Hypervisor on AMD64
ii xen-hypervisor-4.1-amd64 4.1.3-4 amd64
Xen Hypervisor on AMD64
ii xen-linux-system-3.2.0-4-amd64 3.2.32-1 amd64
Xen system with Linux 3.2 on 64-bit PCs (meta-package)
ii xen-linux-system-amd64 3.2+46amd64
Xen system with Linux for 64-bit PCs (meta-package)
ii xen-system-amd64 4.1.3-4 amd64
Xen System on AMD64 (meta-package)
ii xen-tools 4.3.1-1 all
Tools to manage Xen virtual servers
ii xen-utils-4.1 4.1.3-4 amd64
XEN administrative tools
ii xen-utils-common 4.1.3-4 all
Xen administrative tools - common files
ii xenstore-utils 4.1.3-4 amd64
Xenstore utilities for Xen
root@pruebas-xen-egoitz:~# xm list
NameID Mem VCPUs State
Time(s)
Domain-0 0 6908 8 r- 1526.2
freebsd90js.ramattack.net 24 512 2 -b 59.9
I normally create the life cycle with a xm new, later xm start……. the config
file is :
root@pruebas-xen-egoitz:~# cat /etc/xen/freebsd90rjs.ramattack.net.cfg
kernel = '/usr/lib/xen-4.1/boot/hvmloader'
builder = 'hvm'
vcpus = 2
memory
Re: Q on types of xen virtualization
On Thu, 2012-08-09 at 16:30 -0700, arvind viswanathan wrote: Hi, I use a version of Freebsd 7 for my work and I was able to brint it up in Open xen 4.2 However the, OS version I use does not have any xen related files in it (no xen device folder, no xen folder in sys.., no change to the kernel config either) But the server we use supports virtualization. So is the mode that we are currently working in referred to as pure HVM ? I also hear about PV HVM and purely PV. I guess in PV HVM, we use a XEN configuration file and run on a machine supporting virtualization and currently 64 bit machines can only be run this way ? Can some one confirm if my understanding is right. Thanks arvind ___ For full PV support, you can only use a 32bit version of FreeBSD 8 and higher via the XEN kernel config. For HVM mode you can use 64bit FreeBSD 8 and higher with the XENHVM kernel config. There is no PV support in 64bit mode at this time. Sean ___ 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: Q on types of xen virtualization
On Thu, 2012-08-09 at 17:28 -0700, arvind viswanathan wrote: Thanks Sean. the freebsd that I use does not have xen related change set. So is it a Xen HVM or is it simply HVM. Also in case of 64 bit, its mentioned that if xen drivers are supported performance improves ? Any numbers on the improvement on that was achieved with and without the xen drivers ? Thanks Arvind *IF* you are booting a 64bit FreeBSD vm, it will be HVM until you recompiled using the XENHVM kernel config to build and install a new kernel. Sean ___ 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: Compiling error for amd64 on FreeBSD9.0 with XENHVM when include xen console driver.
On Thu, 2012-08-02 at 19:21 -0700, Wei Xu wrote: My Dom0 is Oracle Linux(64bit too), Xen version is 4.0.2, I installed FreeBSD with the official iso image, that's FreeBSD-9.0-RELEASE-i386-dvd1.iso, I'm not sure if it was started as HVM by default, how can i check it? If the VM started up at all, it had to be running via full hardware virtualization. :-) How to convert it to PV support, i just compiled and installed the src with the XEN config in the source tree, I think that will include PV support, since XEN is defined in the options, right? Correct. You compile your i386 kernel with the XEN kernel config, then you need to copy that kernel into your Dom0 and reconfigure the VM to be PV and boot with no HVM options. I'm not sure how to do that with the tools that you have access to, but I did this by editing the xen domU config file for the virtual machine. Here's an example of my DomU config for your reference. Of course, this is a Xen 3 hypervisor, so your changes might have to be different( xl create vs xm create). # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. #kernel = /usr/lib/xen/boot/hvmloader kernel = /var/virt/freebsd-9.current-i386-domu-kernel # # device model to use: only qemu-dm available for now #device_model = '/usr/lib64/xen/bin/qemu-dm' #builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 2048 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = ref9-xen32 arch = i386 #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:03, bridge=xenbr0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:03, bridge=xenbr0, type=vbd' ] # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/ref9-xen32.bin,hda,w', 'file:/var/virt/ref9-xen32_scratch.bin,hdb,w' ] # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' extra = vfs.root.mountfrom=ufs:/dev/ad0p2,kern.hz=100 # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) # # boot CDROM image #boot='d' # boot from DISK file #boot='c' # boot from DHCP/PXE then DISK file boot='nc' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to #vnc = 1 #vncdisplay = 3 #vncunused = 1 #vncpasswd='' #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' acpi = 1 serial='pty' on_reboot='restart' # ___ 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: Compiling error for amd64 on FreeBSD9.0 with XENHVM when include xen console driver.
I run a linux Dom0 (64bit RHEL 5) currently for testing purposes in the freebsd cluster. We have 32bit (PV) and 64bit (HVM) instances running there. How are you installing FreeBSD on your Dom0? Are you starting with HVM support and the ISO image and then converting to PV support? Sean On Thu, 2012-08-02 at 02:36 -0700, Wei Xu wrote: Sean, Thanks for your comments. Current I'm trying to investigate if I can porting the Console Driver to Solaris. I know the uart emulated by QEMU, but it's not my purpose to use it, I just want to try the console driver with Hypervisor itself, Must it bundle with PV? Does XENHVM make sense too? I am not familiar with how the console driver works by comparing to Qemu serial, so I'll be really appreciated if you can give some words about that, thanks. To verify it, I installed a new 32 bit i386 FreeBSD guest domain and compiled the kernel with XEN support, that means already included the console driver, but after I installed the new kernel, system can't boot up after loaded the kernel, both the Xen and the Dom0 are 64 bit, so i guess maybe it can't work for 64bit Hypervisor and Dom0, I wonder how can I verify the console driver? Regards, Wei On Thu, Aug 2, 2012 at 2:02 AM, Sean Bruno sean...@yahoo-inc.com wrote: On Tue, 2012-07-31 at 22:32 -0700, Wei Xu wrote: Hi All, I'm trying to compile new kernel with Xen Console driver on AMD 64 platform, it's not included by default, I got compile error like this , I checked the code and i386 has the pc_ipi_to_irq but amd64 doesn't, look like it hasn't been experience with amd64, is there anyone know whether it can work? thanks. Since there's no PV support for amd64 yet. I don't think you need the console driver. QEMU will emulate the uart(4) device for you and freebsd will use the device as its serial console. From the dom0, you would run xm console vm name. Is this what you mean to do? Sean ___ 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: Compiling error for amd64 on FreeBSD9.0 with XENHVM when include xen console driver.
On Tue, 2012-07-31 at 22:32 -0700, Wei Xu wrote: Hi All, I'm trying to compile new kernel with Xen Console driver on AMD 64 platform, it's not included by default, I got compile error like this , I checked the code and i386 has the pc_ipi_to_irq but amd64 doesn't, look like it hasn't been experience with amd64, is there anyone know whether it can work? thanks. Since there's no PV support for amd64 yet. I don't think you need the console driver. QEMU will emulate the uart(4) device for you and freebsd will use the device as its serial console. From the dom0, you would run xm console vm name. Is this what you mean to do? Sean ___ 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: building kernel modules with XENHVM kernel
On Sun, 2012-06-03 at 10:17 -0700, Colin Percival wrote: Hi all, Ever since the XENHVM kernel config file was added, it has included makeoptionsMODULES_OVERRIDE= I don't see any reason for doing this, and I'd like to remove it; I took it out of the config file I use for EC2 instances a long time ago, and there are people using e.g., zfs.ko without problems. Any objections? Nope, we're not using it over here at Yahoo either. Sean ___ 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/166174: [xen] Problems ROOT MOUNT ERROR lt;freebsd 8.3gt;
The following reply was made to PR kern/166174; it has been noted by GNATS. From: Sean Bruno sean...@yahoo-inc.com To: bug-follo...@freebsd.org, ilsuj...@gmail.com Cc: Subject: Re: kern/166174: [xen] Problems ROOT MOUNT ERROR lt;freebsd 8.3gt; Date: Mon, 04 Jun 2012 15:14:51 -0700 I've got stable/8, stable/9 and -current XEN PV and XENHVM instances running in the freebsd cluster and have done so for quite some time. http://people.freebsd.org/~sbruno/ref8-xen32.txt http://people.freebsd.org/~sbruno/ref8-xen64.txt Does this help at all? Sean ___ 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 Xen Dom0 Support
On Wed, 2012-05-30 at 07:56 -0700, Carsten Heesch wrote: However, if you intend to run 64bit, you are restricted to HVM (use the XENHVM kernel to get better performance from the optimised device drivers for HVM). If you are planning on running 32bit, you can use PV. I think that is still valid for 9.0. And mind you, PV is (or was?) also limited to about 850M memory in the DomU. A couple of nits here, alc@ fixed the PV memory restrictions so the 850M limit isn't a thing anymore: FreeBSD ref9-xen32.freebsd.org 9.0-STABLE FreeBSD 9.0-STABLE #2 r231914: Mon Feb 20 05:30:49 PST 2012 sbr...@ref9-xen32.freebsd.org:/var/tmp/dumpster/scratch/sbruno-scratch/9/sys/XEN i386 [sbruno@ref9-xen32 ~]$ sysctl hw.physmem hw.physmem: 2136674304 And, I think, there is a 64bit PV config now in development at: http://svnweb.freebsd.org/base/projects/amd64_xen_pv/ This is prerequisite work for a dom0 on freebsd which is under development. Stay tuned, things are happening! Sean ___ 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 9-stable
On Mon, 2012-05-07 at 03:50 -0700, Ivan Voras wrote: Hi, Is XENHVM usable on 9-STABLE amd64? I seem to recall some problems early in 9-current. ___ 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 Btw, I do have vm's in the cluster running for this purpose. ref[8,9,10]-xen64 Sean p.s pv 32bit ref[8,9,10]-xen32 ___ 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: i386/XENHVM now works
On Sun, 2012-01-15 at 18:42 -0800, Colin Percival wrote: Hi all, i386/XENHVM now works on HEAD. I'll MFC to stable/9 in a week or two. +1 beer Sean ___ 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: 8.2 releng
On Mon, 2012-01-16 at 02:58 -0800, Richard Kojedzinszky wrote: Dear Sean, I've investigated the problem, and found the following: When starting with # xm create -c /dev/null kernel=/home/krichy/kernel extra=kern.hz=100 memory=464 The kernel boots up, but when adding only one more MB to it, as: # xm create -c /dev/null kernel=/home/krichy/kernel extra=kern.hz=100 memory=465 it does crash. The config is the simple one I've attached previously, with pf and pflog disabled. But again, if I enable pf and pflog, the domain starts with 512MB ram well. Regards, Ah, this one! Alan has resolved these issues in xen on -current at the moment. I suspect an MFC is coming soon: http://svnweb.freebsd.org/base/head/sys/i386/xen/?view=log If you want to try r229007, r228935, r228923, r228747, r228746 and r228522 on stable/8 we'd appreciate the testing. Sean ___ 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: 8.2 releng
No, not the kernel config. See attached example. Sean On Tue, 2012-01-03 at 08:16 -0800, Richard Kojedzinszky wrote: Dear Sean, Attached. Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Tue, 3 Jan 2012, Sean Bruno wrote: Date: Tue, 03 Jan 2012 08:00:28 -0800 From: Sean Bruno sean...@yahoo-inc.com To: Richard Kojedzinszky kri...@tvnetwork.hu Cc: freebsd-xen@freebsd.org freebsd-xen@freebsd.org Subject: Re: 8.2 releng Can you send in your xen domu config? Sean On Tue, 2012-01-03 at 01:56 -0800, Richard Kojedzinszky wrote: Dear users, I forget to mention, If i remove pf and pflog from the config, then the built kernel boots well under xen. Regards, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Tue, 3 Jan 2012, Richard Kojedzinszky wrote: Date: Tue, 3 Jan 2012 10:40:13 +0100 (CET) From: Richard Kojedzinszky kri...@tvnetwork.hu To: freebsd-xen@FreeBSD.org Subject: 8.2 releng Dear xen developers, I have a xen domU with the attached config, and unfortunately it does not boot. I am compiling it with: $ make kernel KERNCONF=DB WERROR= And it only makes a crash dump in the hosts xm dmesg. It is a recent 8.2 releng src tree. What should I change to make this work? Regards, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. ___ 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 # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. #kernel = /usr/lib/xen/boot/hvmloader kernel = /var/virt/freebsd-8-stable-i386-domu-kernel # # device model to use: only qemu-dm available for now #device_model = '/usr/lib64/xen/bin/qemu-dm' #builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 855 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = ref8-xen32 arch = i386 #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=vbd' ] # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/ref8-xen32.bin,hda,w' ] extra = vfs.root.mountfrom=ufs:/dev/ad0s1a # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) # # boot CDROM image #boot='d' # boot from DISK file #boot='c' # boot from DHCP/PXE then DISK file boot='nc' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to #vfb = [ type = vnc, vncdisplay = 1, vncunused = 0, display = TEST ] #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' apci = 1 serial='pty' on_reboot='restart' # ___ 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: PV i386 patch
On Thu, 2011-12-29 at 14:52 -0800, Alan Cox wrote: On 12/29/2011 16:28, Sean Bruno wrote: On Thu, 2011-12-29 at 12:22 -0800, Alan Cox wrote: Please try this patch. It eliminates a race condition that might actually account for some of the crashes in FreeBSD= 9 on Xen. Alan ref10-xen32.freebsd.org has this applied now. Looks ok to me? I know that lmbench's bw_pipe program exercises the code path that I changed if you want to give it a bit more testing. Alan Ok, I ran a thing ... I have a lot of poking around to do in lmbench now. Thanks for pointing me at this. Cursory run with patch xen-pmap.c [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe Pipe bandwidth: 892.52 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 Pipe bandwidth: 982.46 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 -P 2 Pipe bandwidth: 899.34 MB/sec Cursory run of vanilla-current: [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe Pipe bandwidth: 984.37 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 Pipe bandwidth: 977.54 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ ./bw_pipe -N 5 -P 2 Pipe bandwidth: 887.26 MB/sec [sbruno@ref10-xen32 /usr/local/lib/lmbench/bin/i386-freebsd10.0]$ uname -a FreeBSD ref10-xen32.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r228971: Fri Dec 30 18:27:01 UTC 2011 sbr...@ref10-xen32.freebsd.org:/var/tmp/dumpster/scratch/sbruno-scratch/head/sys/XEN i386 ___ 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: PV i386 patch
On Thu, 2011-12-29 at 12:22 -0800, Alan Cox wrote: Please try this patch. It eliminates a race condition that might actually account for some of the crashes in FreeBSD = 9 on Xen. Alan ref10-xen32.freebsd.org has this applied now. Looks ok to me? Sean ___ 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: PV i386 patch
On Tue, 2011-12-27 at 22:14 -0800, Adrian Chadd wrote: On 27 December 2011 15:24, Sean Bruno sean...@yahoo-inc.com wrote: Initial testing looks ok from here. Single CPU PV DomU is up and running as ref10-xen32.f.o if you want to poke around at all. I'm updating the HVM enabled ref10-xen64.f.o as well to check it out. Since I don't yet have my test environment going here, is anyone here running (developer) accessible PVM hosts (32 bit) that I can get access to? I can run a whole sleuth of thrashing tests on it to see if it breaks. Thanks, Adrian Yes. I've been keeping a linux dom0 running in the fbsd cluster. Go ahead and poke at ref10-xen32.f.o ... that's what its there for. Sean ___ 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: PV i386 patch
On Tue, 2011-12-27 at 09:40 -0800, Alan Cox wrote: On 12/23/2011 16:25, Sean Bruno wrote: On Wed, 2011-12-21 at 12:47 -0800, Alan Cox wrote: Can you please try the attached patch? I'm trying to reduce the number of differences between the native and Xen pmap implementations. Alan Without really looking at the output, I note that this didn't apply cleanly against -head ... can you regenerate it? My bad. I gave you the wrong patch. Try this instead. Alan Initial testing looks ok from here. Single CPU PV DomU is up and running as ref10-xen32.f.o if you want to poke around at all. I'm updating the HVM enabled ref10-xen64.f.o as well to check it out. Sean ___ 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: PV i386 patch
On Wed, 2011-12-21 at 12:47 -0800, Alan Cox wrote: Can you please try the attached patch? I'm trying to reduce the number of differences between the native and Xen pmap implementations. Alan I will test this today, this should apply against 9 and -current ? Sean ___ 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: PV i386 patch
On Tue, 2011-12-20 at 10:49 -0800, Alan Cox wrote: On 12/20/2011 07:28, Sean Bruno wrote: The code that panics shouldn't even exist in the Xen pmap. Try the attached patch. Alan Indeed how on earth did we ever use this stuff? :-) Tested to 2G on ref9-xen32.f.o should I go any higher? Sure. Right now, I don't know of any reason that it should crash with more memory. :-) Do either of you know if there is a PR in gnats for this 768 MB limitation bug that I should mention in the commit log? Alan No, I just checked and I didn't put a PR in ... lame. I think I discussed it with colin or kip, but I don't remember if we ever figured out anything else. Sean ___ 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: PV i386 patch
On Sat, 2011-12-17 at 18:01 -0800, Colin Percival wrote: On 12/17/11 16:56, Sean Bruno wrote: This seems happy on our ref9 VMs. I don't suppose this means I can go above 768M of Ram now? Can't hurt to try... whatever the problem is with our code and large amounts of RAM, the fact that it's an insta-panic during paging setup suggests that it's something at a similar level of fail. Nope, insta panic ... early though. 768M works, 1024M panics. [root@xen1 sbruno]# /usr/sbin/xm create -c ref9-xen32 Using config file /etc/xen/ref9-xen32. Started domain ref9-xen32 (id=109) WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 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.0-PRERELEASE #0: Sat Dec 17 16:13:02 PST 2011 sbr...@ref9-xen32.freebsd.org:/dumpster/scratch/sbruno-scratch/9/sys/i386/compile/XEN i386 WARNING: WITNESS option enabled, expect reduced performance. panic: pmap_init: page table page is out of range cpuid = 0 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at 0xc0181d7a: movl$0,0xc0478174 ___ 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: PV i386 patch
On Fri, 2011-12-16 at 11:32 -0800, Alan Cox wrote:
Is anyone here actively working on fixing problems with SMP support
under PV i386? While doing some other maintenance on the
vm_page_alloc() callers in the source tree, I happened to take a look at
cpu_initialize_context() in mp_machdep.c. This function is involved in
bringing up the 2nd, 3rd, etc. CPUs on an SMP system. I spotted a
couple obvious errors. First, the size parameter given to kmem_*()
functions is expected to be in terms of bytes and not pages. Second, I
believe that PV i386 requires PAE to be used. If so, there are out of
range accesses to the array m[].
Index: i386/xen/mp_machdep.c
===
--- i386/xen/mp_machdep.c (revision 228561)
+++ i386/xen/mp_machdep.c (working copy)
@@ -810,7 +810,7 @@ cpu_initialize_context(unsigned int cpu)
{
/* vcpu_guest_context_t is too large to allocate on the stack.
* Hence we allocate statically and protect it with a lock */
- vm_page_t m[4];
+ vm_page_t m[NPGPTD + 2];
static vcpu_guest_context_t ctxt;
vm_offset_t boot_stack;
vm_offset_t newPTD;
@@ -831,8 +831,8 @@ cpu_initialize_context(unsigned int cpu)
pmap_zero_page(m[i]);
}
- boot_stack = kmem_alloc_nofault(kernel_map, 1);
- newPTD = kmem_alloc_nofault(kernel_map, NPGPTD);
+ boot_stack = kmem_alloc_nofault(kernel_map, PAGE_SIZE);
+ newPTD = kmem_alloc_nofault(kernel_map, NPGPTD * PAGE_SIZE);
ma[0] = VM_PAGE_TO_MACH(m[0])|PG_V;
#ifdef PAE
@@ -854,7 +854,7 @@ cpu_initialize_context(unsigned int cpu)
nkpt*sizeof(vm_paddr_t));
pmap_qremove(newPTD, 4);
- kmem_free(kernel_map, newPTD, 4);
+ kmem_free(kernel_map, newPTD, 4 * PAGE_SIZE);
/*
* map actual idle stack to boot_stack
*/
This seems happy on our ref9 VMs. I don't suppose this means I can go
above 768M of Ram now?
[root@xen1 sbruno]# /usr/sbin/xm create -c ref9-xen32
Using config file /etc/xen/ref9-xen32.
Started domain ref9-xen32 (id=106)
WARNING: loader(8) metadata is missing!
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2011 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.0-PRERELEASE #0: Sat Dec 17 16:13:02 PST 2011
sbr...@ref9-xen32.freebsd.org:/dumpster/scratch/sbruno-scratch/9/sys/i386/compile/XEN
i386
WARNING: WITNESS option enabled, expect reduced performance.
Xen reported: 2493.756 MHz processor.
Timecounter ixen frequency 1953125 Hz quality 0
CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.76-MHz
686-class CPU)
Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17
Stepping = 6
Features=0xbfe3fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1
AMD Features=0x2010NX,LM
AMD Features2=0x1LAHF
real memory = 805306368 (768 MB)
avail memory = 776830976 (740 MB)
[XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0)
[XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1)
[XEN] xen_rtc_probe: probing Hypervisor RTC clock
rtc0: Xen Hypervisor Clock on motherboard
[XEN] xen_rtc_attach: attaching Hypervisor RTC clock
xenstore0: XenStore on motherboard
xc0: Xen Console on motherboard
Event timer ixen quality 600
Timecounters tick every 10.000 msec
xenbusb_front0: Xen Frontend Devices on xenstore0
[XEN] hypervisor wallclock nudged; nudging TOD.
xn0: Virtual Network Interface at device/vif/0 on xenbusb_front0
xn0: Ethernet address: 00:16:3e:00:00:03
xenbusb_back0: Xen Backend Devices on xenstore0
xctrl0: Xen Control Device on xenstore0
xn0: backend features: feature-sg feature-gso-tcp4
xbd0: 10240MB Virtual Block Device at device/vbd/768 on xenbusb_front0
xbd0: attaching as ad0
Timecounter TSC frequency 2493756000 Hz quality 800
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from ufs:/dev/ad0p2 []...
rtc0: [XEN] xen_rtc_gettime
rtc0: [XEN] xen_rtc_gettime: wallclock 1313550543 sec; 871707442 nsec
rtc0: [XEN] xen_rtc_gettime: uptime 10619933 sec; 620343100 nsec
rtc0: [XEN] xen_rtc_gettime: TOD 1324170477 sec; 492050542 nsec
Setting hostuuid: 1c127834-ab5a-c2e4-7b24-5ea29d364d9d.
Setting hostid: 0xdea9fbfd.
Entropy harvesting: interrupts ethernet point_to_point kickstart.
Starting file system checks:
/dev/ad0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ad0p2: clean, 1874771 free (883 frags, 234236 blocks, 0.0%
fragmentation)
Mounting local file systems:.
Setting hostname: ref9-xen32.freebsd.org.
xn0: link state changed to DOWN
xn0: link state
Re: PV i386 patch
I'll test this out on the VMs in the fbsd cluster later.
Sean
On Fri, 2011-12-16 at 11:32 -0800, Alan Cox wrote:
Is anyone here actively working on fixing problems with SMP support
under PV i386? While doing some other maintenance on the
vm_page_alloc() callers in the source tree, I happened to take a look at
cpu_initialize_context() in mp_machdep.c. This function is involved in
bringing up the 2nd, 3rd, etc. CPUs on an SMP system. I spotted a
couple obvious errors. First, the size parameter given to kmem_*()
functions is expected to be in terms of bytes and not pages. Second, I
believe that PV i386 requires PAE to be used. If so, there are out of
range accesses to the array m[].
Index: i386/xen/mp_machdep.c
===
--- i386/xen/mp_machdep.c (revision 228561)
+++ i386/xen/mp_machdep.c (working copy)
@@ -810,7 +810,7 @@ cpu_initialize_context(unsigned int cpu)
{
/* vcpu_guest_context_t is too large to allocate on the stack.
* Hence we allocate statically and protect it with a lock */
- vm_page_t m[4];
+ vm_page_t m[NPGPTD + 2];
static vcpu_guest_context_t ctxt;
vm_offset_t boot_stack;
vm_offset_t newPTD;
@@ -831,8 +831,8 @@ cpu_initialize_context(unsigned int cpu)
pmap_zero_page(m[i]);
}
- boot_stack = kmem_alloc_nofault(kernel_map, 1);
- newPTD = kmem_alloc_nofault(kernel_map, NPGPTD);
+ boot_stack = kmem_alloc_nofault(kernel_map, PAGE_SIZE);
+ newPTD = kmem_alloc_nofault(kernel_map, NPGPTD * PAGE_SIZE);
ma[0] = VM_PAGE_TO_MACH(m[0])|PG_V;
#ifdef PAE
@@ -854,7 +854,7 @@ cpu_initialize_context(unsigned int cpu)
nkpt*sizeof(vm_paddr_t));
pmap_qremove(newPTD, 4);
- kmem_free(kernel_map, newPTD, 4);
+ kmem_free(kernel_map, newPTD, 4 * PAGE_SIZE);
/*
* map actual idle stack to boot_stack
*/
___
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: [CFT][PATCH] Netfront fixes for FreeBSD-head
On Mon, 2011-09-12 at 16:36 -0700, Justin T. Gibbs wrote: Folks, I'm planning to ask RE for permission to merge the following netfront fixes (listed below) into 9.0/head. Before I do so, I'd appreciate some community testing on the proposed patch set (attached). The main areas of concern are: o TSO/LRO and performance o Compatibility with NetBSD and other Dom0s that lack sg or TSO/LRO support. o Compatibility with configurations enabling ioemu on an interface. Thanks, Justin Should these be applied with the suspend/resume enhancements? Sean ___ 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/CFR] Improved Xen Suspend/Resume Support
On Thu, 2011-09-01 at 10:55 -0700, Justin T. Gibbs wrote: On Sep 1, 2011, at 11:40 AM, Sean Bruno sean...@yahoo-inc.com wrote: On Thu, 2011-09-01 at 09:55 -0700, Justin T. Gibbs wrote: This work was sponsored by BQ Internet Corporation and they have successfully migrated 100+ FreeBSD VMs with these changes (slightly modified for use in 8.x). I'd like to have feedback from other developers and FreeBSD Xen users before submitting this and/or asking for approval to push them into 9.0. Thanks, Justin Firing these up on ref9-xen64/32 momentarily. What's the magic foo to get patch to understand p4 stuffs? Sean Only some p4 commands generate 100% patch friendly output and I neglected to use those here. You can either just feed the file name into path when it asks or I can regenerate the doffs when I get back to my desk. Sorry about that. :-( -- Justin Aye, I did the latter to move along. No worries. looks like ref9-xen64 is up on this patch set. I shall try some suspend resume things with the xen 3.4 tools I have on xen1.f.o Sean ___ 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/CFR] Improved Xen Suspend/Resume Support
On Thu, 2011-09-01 at 09:55 -0700, Justin T. Gibbs wrote: This work was sponsored by BQ Internet Corporation and they have successfully migrated 100+ FreeBSD VMs with these changes (slightly modified for use in 8.x). I'd like to have feedback from other developers and FreeBSD Xen users before submitting this and/or asking for approval to push them into 9.0. Thanks, Justin hrm ... am I doing it right? [root@xen1 xen]# xm suspend ref9-xen64 Error: Domain is not managed by Xend lifecycle support. Usage: xm suspend DomainName Suspend a Xend managed domain [root@xen1 xen]# rpm -q -a|grep xen xen-libs-3.0.3-120.el5_6.2 xen-3.4.3-5.el5 xen-libs-3.4.3-5.el5 kernel-xen-2.6.18-238.12.1.el5 [root@xen1 xen]# Sean ___ 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/CFR] Improved Xen Suspend/Resume Support
On Thu, 2011-09-01 at 11:32 -0700, Justin T. Gibbs wrote: On Sep 1, 2011, at 12:05 PM, Sean Bruno sean...@yahoo-inc.com wrote: On Thu, 2011-09-01 at 09:55 -0700, Justin T. Gibbs wrote: This work was sponsored by BQ Internet Corporation and they have successfully migrated 100+ FreeBSD VMs with these changes (slightly modified for use in 8.x). I'd like to have feedback from other developers and FreeBSD Xen users before submitting this and/or asking for approval to push them into 9.0. Thanks, Justin hrm ... am I doing it right? [root@xen1 xen]# xm suspend ref9-xen64 Error: Domain is not managed by Xend lifecycle support. Usage: xm suspend DomainName Suspend a Xend managed domain [root@xen1 xen]# rpm -q -a|grep xen xen-libs-3.0.3-120.el5_6.2 xen-3.4.3-5.el5 xen-libs-3.4.3-5.el5 kernel-xen-2.6.18-238.12.1.el5 [root@xen1 xen]# Sean The domain must be managed. You can use xm new config_file to create a managed domain. -- Justin HVM enabled 9 test looks good I think. I suspended a VM, and resumed it. I assume that this is what we wanted to excercise. What other things can I do to test this code? Sean ___ 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: amd64 HVM(+PV) domUs: losing 10+ minutes a day
On Wed, 2011-08-24 at 02:24 -0700, DeuZa wrote: I tried setting machdep_disable_rtc_set to 1, but it made no difference. Hello, Same thing here wth machdep_disable_rtc_set 1, always : Aug 24 10:00:06 mouette kernel: rtc0: [XEN] xen_rtc_settime DeuZa: Are you running i386 PV or amd64/HVM+PV ? I just check on this VPS it's i386 It's your ntpd is up and running with machdep.independent_wallclock=1 ?? Regards, Just to be clear, did you set the /proc/sys/xen/independent_wallclock to 1 on the dom0 ? sean ___ 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: amd64 HVM(+PV) domUs: losing 10+ minutes a day
On Mon, 2011-08-22 at 10:37 -0700, Hugo Silva wrote: On 08/22/11 16:43, DeuZa wrote: 2011/8/22 Hugo Silva h...@barafranca.com Hello, Hello Hugo, I was in the same cas (I think) I use a workaround on my VPS : machdep.independent_wallclock: 1 And the ntpd is fine now, I know it's just a workaround, but practice for running ntpd on Xen instances Regards, Hi, This oid does not appear to exist in the domU. Found some references in google, but not much. May it be that it is only present on the i386 PV port? Regards, Hugo Huh, this used to exist. But anyway, try this: http://forums.freebsd.org/showpost.php?p=105415postcount=15 Sean ___ 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
HVM boot fail, BETA-1 and current
Tried to boot up an BETA-1 XENHVM kernel today, apparently CAMATA doesn't work in this environment. Let me know if you want access to this VM as its in the cluster and I can trivially get you on the machine. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive C: is disk0 BIOS 639kB/2096128kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (r...@farrell.cse.buffalo.edu, Thu Jul 28 16:09:55 UTC 2011) Loading /boot/defaults/loader.conf /boot/kernel/kernel data=0xbb97c0 data=0x1431d0+0x2bc450 syms=[0x8 +0x110da8+0x8+0xf8650] - __ _ _ | | | _ \ / | __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ \___ \| | | | | | | | | __/ __/| |_) |) | |__| | | | | | |||| | | | |_| |_| \___|\___||/|_/|_/``` ` s` `.---...--.``` -/ �Welcome to FreeBSD�� � +o .--` /y:` +. � � yo`:.:o ` +- � 1. Boot [ENTER]� y/ -/` -o/ � 2. [Esc]ape to loader prompt � .- ::/sy +:. � 3. Reboot � / `-- / � � `: :` � Options: � `: :` � 4. [A]CPI Support: Enabled � / / � 5. Boot Safe [M]ode: NO� .- -. � 6. Boot [S]ingle User: NO � -- -. � 7. Boot [V]erbose: NO �`:` `:` � � .-- `--. � � .---.. � GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009fc00 SMAP type=02 base=0009fc00 len=0400 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=7ff0 SMAP type=02 base=fc00 len=0400 Table 'FACP' at 0xfc005ee0 Table 'APIC' at 0xfc005fe0 APIC: Found table at 0xfc005fe0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 1: enabled SMP: Added CPU 2 (AP) Copyright (c) 1992-2011 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.0-BETA1 #0 r224482M: Fri Jul 29 16:42:18 PDT 2011 r...@ref9-xen64.freebsd.org:/usr/obj/dumpster/scratch/sbruno-scratch/head/sys/XENHVM amd64 WARNING: WITNESS option enabled, expect reduced performance. Table 'FACP' at 0xfc005ee0 Table 'APIC' at 0xfc005fe0 ACPI: No SRAT table found Preloaded elf kernel /boot/kernel/kernel at 0x815c4000. Hypervisor: Origin = XenVMMXenVMM Calibrating TSC clock ... TSC clock: 2493823785 Hz CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.82-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x80082201SSE3,SSSE3,CX16,SSE4.1,HV AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x0010 - 0x001f, 1048576 bytes (256 pages) 0x015f3000 - 0x7c38, 2061094912 bytes (503197 pages) avail memory = 2045038592 (1950 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM INTR: Adding local APIC 2 as a target 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 x86bios: IVT 0x00-0x0004ff at 0xfe00 x86bios: SSEG 0x001000-0x001fff at 0xff800020d000 x86bios: EBDA 0x09f000-0x09 at 0xfe09f000 x86bios: ROM 0x0a-0x0fefff at 0xfe0a APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xea020 00024 (v02Xen) ACPI: XSDT 0xfc006050 00034 (v01Xen HVM HVML ) ACPI: FACP 0xfc005ee0 000F4 (v04Xen HVM HVML ) ACPI: DSDT 0xfc002c40 0321F (v02Xen HVM INTL 20090220) ACPI: FACS 0xfc002c00 00040 ACPI: APIC 0xfc005fe0 00070 (v02Xen HVM HVML ) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's - intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing
Re: I am trying to install freebsd on Centos 5.6
On Thu, 2011-07-28 at 08:49 -0700, Rafael Mas wrote: Dear Reader, I am new to this list, and also to the installation of Freebsd on a Virtualez Xen box running on Centos 5.6. I am trying to find the proper documentation or tutorial to get this done, and I would like you to guide me with some good tutorials that I can read to get this project accomplish for my current company. I will appreciate all your help on this important matter. Good question. How far did you get and what problems are you experiencing? Sean ___ 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: I am trying to install freebsd on Centos 5.6
Can you post the following? domU xen config for your VM the output of ifconfig -a on the domU the output of uname -a on the domU Sean On Thu, 2011-07-28 at 11:38 -0700, Rafael Mas wrote: Dear Sean, Readers I am having problems right now... :( I was using the Kernel-Xen ver (3.1.2-238-9.1.el5) that is updated from the Centos-Base repo automatically. Reading some forum post on Xen, I decided to update the Xen to its latest Xen version 4.1.1 using a repo http://www.gitco.de/repo/GITCO-XEN4.1.1_x86_64.repo now, the machine starts but without starting any network interface it complains that IRQ Type mismatch when I try to ifup eth1 or 0. I am not sure if this is because changes on the Xen itself or ? . The sad part of this , is that this is one of my production servers. Have anyone have this kind of issue before with this repo ?, can it be solved without reinstalling/repairing the Linux Kernel ? I've attached a picture on this email with the specs of the error, any input will be super appreciated. Best Regards, -Original Message- From: Sean Bruno [mailto:sean...@yahoo-inc.com] Sent: Thursday, July 28, 2011 2:07 PM To: Rafael Mas Cc: freebsd-xen@freebsd.org Subject: Re: I am trying to install freebsd on Centos 5.6 On Thu, 2011-07-28 at 08:49 -0700, Rafael Mas wrote: Dear Reader, I am new to this list, and also to the installation of Freebsd on a Virtualez Xen box running on Centos 5.6. I am trying to find the proper documentation or tutorial to get this done, and I would like you to guide me with some good tutorials that I can read to get this project accomplish for my current company. I will appreciate all your help on this important matter. Good question. How far did you get and what problems are you experiencing? Sean ___ 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 8, i386 PV panic at idle
Simple left my xen domu running over night. The console looks like this: rtc0: [XEN] xen_rtc_settime [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. panic: HYPERVISOR_update_va_mapping(((unsigned long)(sysmaps-CADDR2)), (0x001 | 0x002 | xpmap_ptom(((m)-phys_addr)) | 0x020 | 0x040), UVMF_INVLPG| UVMF_ALL) 0: /dumpster/scratch/sbruno-scratch/8/sys/i386/xen/pmap.c:3400 cpuid = 0 KDB: enter: panic [thread pid 61868 tid 100085 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db bt Tracing pid 61868 tid 100085 td 0xc3e0d2e0 kdb_enter(c0369837,c0369837,c03915fd,e1ae0acc,0,...) at kdb_enter+0x3a panic(c03915fd,c0398e3e,c039848a,d48,c05bc140,...) at panic+0x134 pmap_zero_page(c15d9038,e,0,40,e1ae0c14,...) at pmap_zero_page+0x112 vm_fault(c350e0ec,bf7ee000,2,8,bf7eed78,...) at vm_fault+0x1201 dblfault_handler() at dblfault_handler+0x4d7 --- trap 0x17, eip = 0, esp = 0, ebp = 0 --- The Dom0 has the following on its console: entOS release 5.6 (Final) Kernel 2.6.18-238.12.1.el5xen on an x86_64 xen1.freebsd.org login: (XEN) mm.c:2315:d146 Bad type (saw 4802 != exp e000) for mfn 1269f1 (pfn 25d7a) (XEN) mm.c:807:d146 Error getting mfn 1269f1 (pfn 25d7a) from L1 entry 0001269f1063 for l1e_owner=146, pg_owner=146 DomU config: # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. #kernel = /usr/lib/xen/boot/hvmloader kernel = /var/virt/freebsd-8-stable-i386-domu-kernel # # device model to use: only qemu-dm available for now #device_model = '/usr/lib64/xen/bin/qemu-dm' #builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 855 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = ref8-xen32 arch = i386 #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=vbd' ] # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/FreeBSD-8.2-RELEASE-i386-disc1.iso,hdc:cdrom,r', 'file:/var/virt/ref8-xen32.bin,hda,w' ] extra = vfs.root.mountfrom=ufs:/dev/ad0s1a # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) # # boot CDROM image #boot='d' # boot from DISK file boot='c' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to #vfb = [ type = vnc, vncdisplay = 1, vncunused = 0, display = TEST ] #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' serial='pty' on_reboot='restart' # ___ freebsd-xen@freebsd.org
FreeBSD 8, PV, i386 panic with vcpus 1
I assume then, that the i386 PV instance cannot do more than 1 CPU at this time? sean Started domain ref8-xen32 (id=120) WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2011 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 8.2-STABLE #1 r224449: Tue Jul 26 09:53:36 PDT 2011 sbr...@ref8-xen32.freebsd.org:/usr/obj/dumpster/scratch/sbruno-scratch/8/sys/XEN i386 WARNING: WITNESS option enabled, expect reduced performance. Xen reported: 2493.746 MHz processor. Timecounter ixen frequency 1953125 Hz quality 0 CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.75-MHz 686-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0xbfe3fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xce3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,DCA,SSE4.1 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 805306368 (768 MB) avail memory = 777650176 (741 MB) gdtpfn=20103f pdptpfn=3d0be panic: HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt): /dumpster/scratch/sbruno-scratch/8/sys/i386/xen/mp_machdep.c:930 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x3a: movl$0,kdb_why db db db db bt Tracing pid 0 tid 0 td 0xc03dec90 kdb_enter(c0369837,c0369837,c03915fd,c06b4ca8,0,...) at kdb_enter+0x3a panic(c03915fd,c03983a2,c0398124,3a2,c0398124,...) at panic+0x134 start_all_aps(c0396bf2,1,c03b2890,c036e574,0,...) at start_all_aps+0x7d4 cpu_mp_start(c03f3234,c036e574,0,1,fff,...) at cpu_mp_start+0x155 smp_topo_find(0,6040800,6040800,6b9000,0,...) at smp_topo_find+0xbf mi_startup(6b9000,0,0,0,0,...) at mi_startup+0xac btext() at btext+0x95 ___ 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 Xen PV i386 -- 855MB Max?
On Tue, 2011-07-26 at 12:01 -0700, K. Macy wrote: It's an artifact of the initialization code and how the xen domain builder configures the initial mapped memory. I've come against this and fixed this issue in the past but I guess either the domain builder has changed or the initial code has bit rotted. I can't commit so ask Colin if he can fix. Cheers I have one of those commit bits if you have something in mind. sean ___ 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 PV i386 panics
On Tue, 2011-07-26 at 11:58 -0700, Colin Percival wrote: On 07/26/11 11:35, Sean Bruno wrote: I assume then, that the i386 PV instance cannot do more than 1 CPU at this time? Correct. SMP support was clearly started but never completed. I note that if I scale the i386 PV Xen kernel past 855MB, I get an insta panic at boot. I assume that there's a hard limit on the amount of RAMS we can use here? There's a problem somewhere in FreeBSD's PV machine init code, but I haven't had an opportunity to track it down yet. I hope to look at this some time soon (if I can access the xen box in the cluster?) but I've been swamped lately. Yup, you're on my list to get access today. I'll get kerberos up and running on the hypervisor so you can screw around in a bit. Sean ___ 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 8, PV i386 VNC fails?
Probably not doing it right. When I switched from pure HVM to PV on the i386 VMs in the cluster, VNC stopped working all together. Did I do it wrong? I've tried the following: vnc = 1 vncdisplay = 1 vncunused = 1 vncpasswd='' and vfb = [ type = vnc, vncdisplay = 1, vncunused = 1, vncpasswd='' ] The vfb = [] syntax seems to hang the VM on frame buffer initialization and it will not post. The old style syntax seems to allow the host to boot, but there is no VNC listening on the host. Understand that the old style syntax works just fine in HVM mode. Sean ___ 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 8, PV i386 VNC fails?
On Tue, 2011-07-26 at 15:18 -0700, Luke S. Crawford wrote: On Tue, Jul 26, 2011 at 03:04:48PM -0700, Colin Percival wrote: On 07/26/11 14:48, Sean Bruno wrote: Probably not doing it right. When I switched from pure HVM to PV on the i386 VMs in the cluster, VNC stopped working all together. Did I do it wrong? Is it possible to use PV with VNC? I thought under PV there wasn't any emulated console, just the Xen paravirtual console which lets you read and write characters as on a serial console. It's possible, redhat built a paravirtualized framebuffer to give pv guests a framebuffer http://www.xen.org/files/xensummit_4/Xenpvfb07_Armbruster.pdf I imagine the problem is probably hypervisor dependent; I mean, I don't know anyone who actually used the paravirtualized framebuffer, so it's probably not well tested, and may suffer from bit rot as other features are added to xen. I tested it, /I believe/ on rhel/centos 5.3. ___ I think that sort of makes sense to me. That is, there would need to be a PV framebuffer driver for PV mode to use it. I guess. Sean ___ 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 8, PV i386 Console
I can't quite tell what's happening (perhaps its ntpd and Xen something here), but this appears on the VM console about every 10 seconds. [XEN] hypervisor wallclock nudged; nudging TOD. [XEN] hypervisor wallclock nudged; nudging TOD. if the system is completely idle, I see: 26 Jul 15:56:02 ntpdate[543]: poll(): nfound = 0, error: Interrupted system call [XEN] hypervisor wallclock nudged; nudging TOD. thoughts? Sean ___ 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
Ok, so why is Sean whining so much today
I'm almost done building a test reference system in the Yahoo portion of the FreeBSD cluster. Nothing special, but I'm trying to get you folks some testing resources that are capable of being used for testing and development of Xen. The emails I'm sending are just the bits of things that I'm seeing fall out of a basic installation of 4 VMs (32/64bit version of 8/HEAD). Over the next few days I'll be releasing them for your general consumption and taking suggestions on what we should be doing with them. I'm hopeful that we can come up with some ideas to make the DomU code more accessible to end users. So, if you see things you'd like tested, or somewhere to run an idea, let use know on the clusteradm@ mail list and we'll take care of you. Sean ___ 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
Some success, some questions
I've made some significant progress on the freebsd.org xen hosting machines (no dom0 support yet, but I'm working on it). I've installed a netbsd-current dom0 and the 3.3.2 xen hypervisor on xen1.freebsd.org and started up a freebsd-current DomU with the XENHVM kernel installed. I've attached the dmesg and the xen config for xen2.freebsd.org to this message. I've been crashing the hypervisor pretty reliably by setting the DomU to use multiple CPUs. Not sure if this is a Xen or NetBSD thing, but for now i'm leaving vcpus set to 1. 1. How do I switch the networking vif entry to use the netfront xn0 driver instead of emulating a e1000? 2. What tests would people like to see on this? 3. Is anyone working on OpenStack or Ganetti for Free/NetBSD? Sean # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. kernel = /usr/pkg/lib/xen/boot/hvmloader device_model = '/usr/lib/xen/bin/qemu-dm' builder='hvm' # Initial memory allocation (in megabytes) for the new domain. memory = 4098 # number of CPUS vcpus = 1 # A name for your domain. All domains must have different names. name = fbsd9 #Network interface. By default emules a realtek 8139. For a NetBSD guest you # have to disable re(4) and let rtk attach to use it. # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0 # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets with # pcn(4) under NetBSD. #vif = [ 'mac=00:16:3e:00:00:14, bridge=bridge0, type=ioemu' ] vif = [ 'mac=00:16:3e:00:00:14, bridge=bridge0, model=e1000' ] # # device model to use: only qemu-dm available for now device_model = '/usr/pkg/libexec/qemu-dm' # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. # For hvm domains you can only use hda to hdd. You can set extra types # (e.g. cdrom) disk = [ 'file:/var/virt/FreeBSD-9.0-CURRENT-201105-amd64-dvd1.iso,hdc:cdrom,r', #'file:/var/virt/FreeBSD-9.0-CURRENT-201101-amd64-disc1.iso,hdc:cdrom,r', 'file:/var/virt/vmtest9_amd64.bin,hda,w' ] # floppy images; this doesn't seem to work currently. Use a iso image instead. #fda = '/home/domains/boot1.fs' # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry # before) boot='c' # By default, 'xm create' will try to open an X window on the current display # for the virtal framebuffer. You can have the virtal framebuffer in vnc # instead, and connect using a vnc client (using localhost:$vncdisplay) # If vncunused is set to 1 (this is the default value), vncdisplay # will be set to the first unused port; so it's recommended to vnc = 1 vncdisplay = 1 vncunused = 1 vncpasswd='' #Xen emulates a PS/2 mouse, but the pointer in the guest has difficulties # tracking the absolute position. Xen can emulate a USB tablet in addition # to the mouse which will report the absolute position of the pointer, # and make the mouse much easier to use. # usb=1 usbdevice='tablet' #usbdevice='mouse' serial='pty' on_reboot='restart' # From: Sean Bruno sbr...@xen2.freebsd.org To: sbr...@freebsd.org sbr...@freebsd.org Subject:dmesg from xenhvm on netbsd dom0 Date: Tue, 24 May 2011 15:10:29 -0700 Copyright (c) 1992-2011 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.0-CURRENT #0 r39: Tue May 24 12:06:26 PDT 2011 root@xen2:/usr/obj/usr/home/sbruno/head/sys/XENHVM amd64 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Xeon(R) CPU L5420 @ 2.50GHz (2493.82-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 6 Model = 17 Stepping = 6 Features=0x781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2 Features2=0x80082201SSE3,SSSE3,CX16,SSE4.1,HV AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF real memory = 4297064448 (4098 MB) avail memory = 4113154048 (3922 MB) Event timer LAPIC quality 400 ACPI APIC Table: Xen HVM ioapic0: Changing APIC ID to 1 MADT: Forcing active-low polarity and level trigger
domU config for NetBSD Dom0
Does anyone have a working HVM config for a FreeBSD DomU under the NetBSD Dom0? Sean ___ 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 drivers for FreeBSD
On Wed, 2010-11-24 at 09:03 -0800, Yuriy Kohut wrote: Hi, It is for amd64 only, correct ? Do you know is it stable enough ? --- Yura The version in -CURRENT and FreeBSD 8 that Justin is talking about is very stable. I will be updating FreeBSD 7 and 6 today. You will need to update from source to get this version as it is not on the release ISOs We are using it a lot at Yahoo. It is very stable. Sean ___ 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
