Re: FreeBSD PVHVM call for testing
On 05/22/13 04:45, Roger Pau Monné wrote: > On 18/05/13 17:44, Colin Percival wrote: >> That seems to work. dmesg is attached. Are there any particular tests >> you'd like me to run? > > I have not tested ZFS, that might be a good one. If you are running this > on Xen 3.4 the behaviour should be the same as without this patches, so > there shouldn't be many differences. I don't use ZFS personally, so I'm not sure exactly what tests to run on it; hopefully someone else can take care of that. > If you could try that on Xen 4.0 at least (if I remember correctly > that's when the vector callback was introduced), you should see the PV > timer getting attached, and a performance increase. Testing on a cr1.8xlarge EC2 instance, I get Xen 4.2, but it ends up with a panic -- console output below. I can get a backtrace and possibly even a dump if those would help. Booting [/boot/kernel/kernel]... -\|/-\|GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base= len=0009e000 SMAP type=02 base=0009e000 len=2000 SMAP type=02 base=000e len=0002 SMAP type=01 base=0010 len=eff0 SMAP type=02 base=fc00 len=0400 SMAP type=01 base=0001 len=003c1900 Table 'FACP' at 0xfc014980 Table 'APIC' at 0xfc014a80 APIC: Found table at 0xfc014a80 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 1: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 2: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 3: enabled SMP: Added CPU 6 (AP) MADT: Found CPU APIC ID 8 ACPI ID 4: enabled SMP: Added CPU 8 (AP) MADT: Found CPU APIC ID 10 ACPI ID 5: enabled SMP: Added CPU 10 (AP) MADT: Found CPU APIC ID 12 ACPI ID 6: enabled SMP: Added CPU 12 (AP) MADT: Found CPU APIC ID 14 ACPI ID 7: enabled SMP: Added CPU 14 (AP) MADT: Found CPU APIC ID 32 ACPI ID 8: enabled SMP: Added CPU 32 (AP) MADT: Found CPU APIC ID 34 ACPI ID 9: enabled SMP: Added CPU 34 (AP) MADT: Found CPU APIC ID 36 ACPI ID 10: enabled SMP: Added CPU 36 (AP) MADT: Found CPU APIC ID 38 ACPI ID 11: enabled SMP: Added CPU 38 (AP) MADT: Found CPU APIC ID 40 ACPI ID 12: enabled SMP: Added CPU 40 (AP) MADT: Found CPU APIC ID 42 ACPI ID 13: enabled SMP: Added CPU 42 (AP) MADT: Found CPU APIC ID 44 ACPI ID 14: enabled SMP: Added CPU 44 (AP) MADT: Found CPU APIC ID 46 ACPI ID 15: enabled SMP: Added CPU 46 (AP) MADT: Found CPU APIC ID 1 ACPI ID 16: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 3 ACPI ID 17: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 5 ACPI ID 18: enabled SMP: Added CPU 5 (AP) MADT: Found CPU APIC ID 7 ACPI ID 19: enabled SMP: Added CPU 7 (AP) MADT: Found CPU APIC ID 9 ACPI ID 20: enabled SMP: Added CPU 9 (AP) MADT: Found CPU APIC ID 11 ACPI ID 21: enabled SMP: Added CPU 11 (AP) MADT: Found CPU APIC ID 13 ACPI ID 22: enabled SMP: Added CPU 13 (AP) MADT: Found CPU APIC ID 15 ACPI ID 23: enabled SMP: Added CPU 15 (AP) MADT: Found CPU APIC ID 33 ACPI ID 24: enabled SMP: Added CPU 33 (AP) MADT: Found CPU APIC ID 35 ACPI ID 25: enabled SMP: Added CPU 35 (AP) MADT: Found CPU APIC ID 37 ACPI ID 26: enabled SMP: Added CPU 37 (AP) MADT: Found CPU APIC ID 39 ACPI ID 27: enabled SMP: Added CPU 39 (AP) MADT: Found CPU APIC ID 41 ACPI ID 28: enabled SMP: Added CPU 41 (AP) MADT: Found CPU APIC ID 43 ACPI ID 29: enabled SMP: Added CPU 43 (AP) MADT: Found CPU APIC ID 45 ACPI ID 30: enabled SMP: Added CPU 45 (AP) MADT: Found CPU APIC ID 47 ACPI ID 31: enabled SMP: Added CPU 47 (AP) MADT: Found CPU APIC ID 0 ACPI ID 32: disabled MADT: Found CPU APIC ID 0 ACPI ID 33: disabled MADT: Found CPU APIC ID 0 ACPI ID 34: disabled MADT: Found CPU APIC ID 0 ACPI ID 35: disabled MADT: Found CPU APIC ID 0 ACPI ID 36: disabled MADT: Found CPU APIC ID 0 ACPI ID 37: disabled MADT: Found CPU APIC ID 0 ACPI ID 38: disabled MADT: Found CPU APIC ID 0 ACPI ID 39: disabled MADT: Found CPU APIC ID 0 ACPI ID 40: disabled MADT: Found CPU APIC ID 0 ACPI ID 41: disabled MADT: Found CPU APIC ID 0 ACPI ID 42: disabled MADT: Found CPU APIC ID 0 ACPI ID 43: disabled MADT: Found CPU APIC ID 0 ACPI ID 44: disabled MADT: Found CPU APIC ID 0 ACPI ID 45: disabled MADT: Found CPU APIC ID 0 ACPI ID 46: disabled MADT: Found CPU APIC ID 0 ACPI ID 47: disabled MADT: Found CPU APIC ID 0 ACPI ID 48: disabled MADT: Found CPU APIC ID 0 ACPI ID 49: disabled MADT: Found CPU APIC ID 0 ACPI ID 50: disabled MADT: Found CPU APIC ID 0 ACPI ID 51: disabled MADT: Found CPU APIC ID 0 ACPI ID 52: disabled MADT: Found CPU APIC ID 0 ACPI ID 53: disabled MADT: Found CPU APIC ID 0 ACPI ID 54: disabled MADT: Found CPU APIC ID 0 ACPI ID 55: disabled MADT: Found CPU APIC ID 0 ACPI ID 56: disabled MADT: Found CPU APIC ID 0 ACPI ID 57: disabled MADT: Found CPU APIC ID 0 ACPI ID 58: disabled MADT: Found CPU APIC ID 0 ACPI ID 59: disabled MADT: Found CPU APIC
Re: kern/176471: commit references a PR
The following reply was made to PR kern/176471; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/176471: commit references a PR
Date: Wed, 22 May 2013 17:13:21 + (UTC)
Author: gibbs
Date: Wed May 22 17:13:03 2013
New Revision: 250913
URL: http://svnweb.freebsd.org/changeset/base/250913
Log:
Correct panic on detach of Xen PV network interfaces.
dev/xen/netfront:
In netif_free(), properly stop the interface and drain any pending
timers prior to disconnecting from the backend device.
Remove all media and detach our interface object from the system
prior to deleting it.
PR: kern/176471
Submitted by:Roger Pau Monne
Reviewed by: gibbs
MFC after: 1 week
Modified:
head/sys/dev/xen/netfront/netfront.c
Modified: head/sys/dev/xen/netfront/netfront.c
==
--- head/sys/dev/xen/netfront/netfront.c Wed May 22 16:33:28 2013
(r250912)
+++ head/sys/dev/xen/netfront/netfront.c Wed May 22 17:13:03 2013
(r250913)
@@ -2171,10 +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);
-#if 0
- close_netdev(info);
-#endif
+ ifmedia_removeall(&info->sc_media);
+ ether_ifdetach(info->xn_ifp);
+ if_free(info->xn_ifp);
}
static void
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-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: FreeBSD PVHVM call for testing
Hi, I've just successfully run FreeBSD 9.1 based guest with 'pvhvm_v8' based kernel under Xen 3.4.4. Hypervisor details: # xm info host : *** release: 2.6.18-348.2.1.el5xen version: #1 SMP Tue Mar 5 17:05:33 EST 2013 machine: x86_64 nr_cpus: 4 nr_nodes : 1 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 2128 hw_caps: bfebfbff:28100800::0340:009ce3bd::0001: virt_caps : hvm total_memory : 6135 free_memory: 262 node_to_cpu: node0:0-3 node_to_memory : node0:262 xen_major : 3 xen_minor : 4 xen_extra : .4 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 cc_compiler: gcc version 4.1.2 20080704 (Red Hat 4.1.2-52) cc_compile_by : root cc_compile_domain : ** cc_compile_date: Wed Sep 5 18:01:10 EEST 2012 xend_config_format : 4 DomU details: # xm list --long h283bpm53f9rnx (domain (domid 61) (on_crash restart) (uuid a2cbcba9-1d66-87ce-6d2f-412e70eab051) (bootloader_args ) (vcpus 2) (name h283bpm53f9rnx) (on_poweroff destroy) (on_reboot restart) (cpus (() ())) (bootloader ) (maxmem 1024) (memory 1024) (shadow_memory 10) (features ) (on_xend_start ignore) (on_xend_stop ignore) (start_time 1369235607.92) (cpu_time 31.914003553) (online_vcpus 2) (image (hvm (kernel ) (videoram 4) (hpet 0) (stdvga 0) (loader /usr/lib/xen/boot/hvmloader) (vncunused 1) (xen_platform_pci 1) (boot cd) (rtc_timeoffset 7202) (pci ()) (pae 1) (vpt_align 1) (hap 1) (viridian 0) (acpi 1) (localtime 0) (timer_mode 1) (vnc 1) (nographic 0) (guest_os_type default) (pci_msitranslate 1) (apic 1) (monitor 0) (usbdevice tablet) (device_model /usr/lib64/xen/bin/qemu-dm) (pci_power_mgmt 0) (usb 0) (xauthority /root/.Xauthority) (isa 0) (notes (SUSPEND_CANCEL 1)) ) ) (status 2) (state -b) (store_mfn 1044476) (device (vif (bridge xnh5getjoj54ke) (uuid 6133c146-48ea-b7a5-0263-fda98e1a30fe) (script /etc/xen/scripts/vif-bridge) (ip 83.170.81.183) (mac 00:16:3e:a4:02:5a) (vifname t2vd5w22msrv5d) (backend 0) ) ) (device (vbd (protocol x86_64-abi) (uuid dd857cd1-2a4c-ea21-a5a5-e95d811f607a) (bootable 1) (dev hda:disk) (uname phy:/dev/9yblt1m70pdtdp/ddfhogyred6bby) (mode w) (backend 0) (bootable 1) (VDI ) ) ) (device (vbd (protocol x86_64-abi) (uuid 19cae15c-354d-77cb-57ec-dc313f1d05ba) (bootable 0) (dev hdb:disk) (uname phy:/dev/9yblt1m70pdtdp/dhnnwhs6jh9kdd) (mode w) (backend 0) (bootable 0) (VDI ) ) ) (device (vbd (protocol x86_64-abi) (uuid 2b97ec8c-0cc5-7197-f510-63c272449680) (bootable 0) (dev hdc:disk) (uname phy:/dev/9yblt1m70pdtdp/d1jilc7s7jxsaq) (mode w) (backend 0) (bootable 0) (VDI ) ) ) (device (vbd (protocol x86_64-abi) (uuid 1b472270-1ef3-2f49-81f1-031cc00c0eb7) (bootable 0) (dev hdd:cdrom) (uname file:/tools/freebsd/boot-freebsd-generic.iso) (mode r) (backend 0) (bootable 0) (VDI ) ) ) (device (vfb (vncunused 1) (vnc 1) (uuid b3defeea-4acc-1408-9b22-71547a64e705) (location 0.0.0.0:5900) ) ) (device (console (protocol vt100) (location 4) (uuid 58a089ce-a4d0-037e-23e8-9df37b2bd5da) ) ) ) DomU from "inside": # uname -a FreeBSD yurak1.vm 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+03cdadc: Wed May 22 17:47:40 EEST 2013 r...@yurak1.vm:/usr/obj/data/freebsd/sys/XENHVM amd64 I'll also set up one (hope will have some time) under Xen 4.2.2 tomorrow. --- Yura On May 13, 2013, at 21:32 PM, Roger Pau Monné wrote:
Re: [Xen-devel] FreeBSD PVHVM call for testing
On Wed, May 22, 2013 at 01:41:02PM +0200, Roger Pau Monné wrote: > On 21/05/13 19:40, Konrad Rzeszutek Wilk wrote: > > On Mon, May 13, 2013 at 08:32:56PM +0200, Roger Pau Monné wrote: > >> Hello, > >> > >> Recently Justin T Gibbs, Will Andrews and myself have been working on > >> improving the Xen support in FreeBSD. The main goal of this was to bring > >> full PVHVM support to FreeBSD, right now FreeBSD is only using PV > >> interfaces for disk and network interfaces when running as a HVM guest. > >> The main benefits of this changes are that Xen virtual interrupts (event > >> channels) are now delivered to the guest using a vector callback > >> injection, that is a per-cpu mechanism that allows each vCPU to have > >> different interrupts assigned, so for example network and disk > >> interrupts are delivered to different vCPUs in order to improve > >> performance. With this changes FreeBSD also uses PV timers when running > >> as an HVM guest, which should provide better time keeping and reduce the > >> virtualization overhead, since emulated timers are no longer used. PV > >> IPIs can also be used inside a HVM guest, but this will be implemented > >> later. > >> > >> Right now the code is in a state where it can be tested by users, so we > >> would like to encourage FreeBSD and Xen users to test it and provide > >> feedback. > >> > >> The code is available in the following git repository, under the branch > >> pvhvm_v5: > >> > >> http://xenbits.xen.org/gitweb/?p=people/royger/freebsd.git;a=summary > >> > >> Also, I've created a wiki page that explains how to set up a FreeBSD > >> PVHVM for testing: > >> > >> http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM > > > > I tried on my Linux box to do this: > > > > > > HEAD is now at 9b25356... xen-netfront: fix detach of network interfaces > > konrad@phenom:~/git/freebsd$ make kernel-toolchain && make buildkernel > > KERNCONF=XENHVM && make installkernel KERNCONF=XENHVM > > Makefile:123: *** missing separator. Stop. > > > > > > As I thought it would compile the same way you can compile NetBSD - that is > > even on non-BSD distros. Is that not the case? Should I only do this under > > a FreeBSD guest? > > I have never tried to run the FreeBSD build system under something > different than FreeBSD, also keep in mind that installkernel will place > a bunch of FreeBSD files on your Linux box if you manage to run it. The > error itself can probably be fixed by installing and using BSD make > (bmake), but anyway you need a FreeBSD HVM DomU in order to test the > kernel, so why not do the compilation on it? Oh, sure. Just thought that the NetBSD method (which also allows one to build the kernel and the iso) was the same on FreeBSd. Will of course install first the HVM domU and do it again. > ___ freebsd-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: [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"
