Re: Latest current -CURRENT (rev 255904) panics with "device hyperv" on XenServer 6.2
On 04-Oct-2013, at 9:09 PM, Shanker Balan wrote: > On 04-Oct-2013, at 5:35 PM, Sergey Nasonov wrote: > >>> Hi Sergey, >>> >>> Thank you very much for suggesting the workaround. >>> >>> My use case is for users uploading the ISO to CloudStack private cloud and >>> not being able to >>> install FreeBSD 10. As an end user of cloudstack, I don't have access to >>> the hypervisor (XenServer) >>> to make the required param changes. >>> >>> End user's only have the ability to upload ISOs and create VMs and they >>> will hit the panic. >> Ок, in that case you need to change properties of template, based on which >> your users created their VMs. >> >> > > The only user modifiable template setting is the Operating System type. > >> I think it is possible with CloudStack. >> >> > > As of now, its not possible to modify any param-set options via template > settings in CloudStack. Patch has been committed to HEAD. Thanks Roger and Justin. http://lists.freebsd.org/pipermail/svn-src-head/2013-October/052022.html I'll give ALPHA5 a try once the ISO is out. ___ 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 04-Oct-2013, at 5:35 PM, Sergey Nasonov wrote: > >Hi Sergey, > > > >Thank you very much for suggesting the workaround. > > > >My use case is for users uploading the ISO to CloudStack private cloud and > >not being able to > >install FreeBSD 10. As an end user of cloudstack, I don't have access to the > >hypervisor (XenServer) > >to make the required param changes. > > > >End user's only have the ability to upload ISOs and create VMs and they will > >hit the panic. > Ок, in that case you need to change properties of template, based on which > your users created their VMs. > > The only user modifiable template setting is the Operating System type. > I think it is possible with CloudStack. > > As of now, its not possible to modify any param-set options via template settings in CloudStack. Regards. @shankerbalan ___ 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 04-Oct-2013, at 1:02 PM, Sergey Nasonov wrote: > > > >I just tried FreeBSD 10 ALPHA4 ISO. The ISO fails to boot on > >XenServer 6.2 resulting with the same HyperV panic > > > >Regards. > >@shankerbalan > > Hi, > You can disable viridian support for that VM by command: > xe vm-param-set platform:viridian=false uuid= > > Hi Sergey, Thank you very much for suggesting the workaround. My use case is for users uploading the ISO to CloudStack private cloud and not being able to install FreeBSD 10. As an end user of cloudstack, I don't have access to the hypervisor (XenServer) to make the required param changes. End user's only have the ability to upload ISOs and create VMs and they will hit the panic. > after that check platform parameter for FBSD VM by command: > xe vm-param-get param-name=platform uuid= > viridian: false; timeoffset: 0; nx: true; acpi: 1; apic: true; pae: true > > It helps me run FreeBSD 10 ALPHA 4 without problems. > > I have tested live migration with both statis and dynamic memory > configuration. If I set static configuration, for example 512 MB RAM then VM > migration ends fine. VM migration during acive dynamic memory configuration > (512 MB - min 1024 MB - max) triggers huge amount of console messages: > > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe003d291900 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0 > witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70 > uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0 > malloc() at malloc+0x101/frame 0xfe003d291b30 > balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0 > fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0 > --- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 --- > uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) > locked @ /usr/src/sys/dev/xen/balloon/balloon.c:339 > exclusive sleep mutex balloon_mutex (balloon_mutex) r = 0 > (0x816e7138) locked @ /usr/src/sys/dev/xen/balloon/balloon.c:373 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe003d291900 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0 > witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70 > uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0 > malloc() at malloc+0x101/frame 0xfe003d291b30 > balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0 > fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0 > --- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 --- > uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) > locked @ /usr/src/sys/dev/xen/balloon/balloon.c:339 > exclusive sleep mutex balloon_mutex (balloon_mutex) r = 0 > (0x816e7138) locked @ /usr/src/sys/dev/xen/balloon/balloon.c:373 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe003d291900 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0 > witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70 > uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0 > malloc() at malloc+0x101/frame 0xfe003d291b30 > balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0 > fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0 > --- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 --- > uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) > locked @ /usr/src/sys/dev/xen/balloon/balloon.c:339 > exclusive sleep mutex balloon_mutex (balloon_mutex) r = 0 > (0x816e7138) locked @ /usr/src/sys/dev/xen/balloon/balloon.c:373 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe003d291900 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe003d2919b0 > witness_warn() at witness_warn+0x4a8/frame 0xfe003d291a70 > uma_zalloc_arg() at uma_zalloc_arg+0x3b/frame 0xfe003d291ae0 > malloc() at malloc+0x101/frame 0xfe003d291b30 > balloon_process() at balloon_process+0x44a/frame 0xfe003d291bb0 > fork_exit() at fork_exit+0x84/frame 0xfe003d291bf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfe003d291bf0 > --- trap 0, rip = 0, rsp = 0xfe003d291cb0, rbp = 0 --- > uma_zalloc_arg: zone "16" with the following non-sleepable locks held: > exclusive sleep mutex balloon_lock (balloon_lock) r = 0 (0x816e7158) > locked @ /usr/src/sys/dev/xen/balloon/balloon.c:339 > exclusive sleep mutex balloon_mutex (balloon_mutex)
Re: Latest current -CURRENT (rev 255904) panics with "device hyperv" on XenServer 6.2
On 27-Sep-2013, at 9:59 PM, Shanker Balan wrote: > (Doing a proper reply all now) > > On 27-Sep-2013, at 8:34 PM, Roger Pau Monné wrote: > >> 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. >> >> > > > Patch works for me on XenServer 6.2. > > root@fxen1:~ # uname -a > FreeBSD fxen1.lab 10.0-ALPHA3 FreeBSD 10.0-ALPHA3 #1 r255912M: Fri Sep 27 > 15:27:19 IST 2013 r...@fxen1.lab:/usr/obj/usr/src/sys/MYKERNEL amd64 > root@fxen1:~ # > > root@fxen1:~ # sysctl -a | grep ^device | grep "xen\|hyper" > devicehyperv > devicexenpci > > Thank you very much. I just tried FreeBSD 10 ALPHA4 ISO. The ISO fails to boot on XenServer 6.2 resulting with the same HyperV panic Regards. @shankerbalan ___ 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
(Doing a proper reply all now) On 27-Sep-2013, at 8:34 PM, Roger Pau Monné wrote: > 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. > > Patch works for me on XenServer 6.2. root@fxen1:~ # uname -a FreeBSD fxen1.lab 10.0-ALPHA3 FreeBSD 10.0-ALPHA3 #1 r255912M: Fri Sep 27 15:27:19 IST 2013 r...@fxen1.lab:/usr/obj/usr/src/sys/MYKERNEL amd64 root@fxen1:~ # root@fxen1:~ # sysctl -a | grep ^device | grep "xen\|hyper" device hyperv device xenpci Thank you very much. Regards. @shankerbalan ___ 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: Latest current -CURRENT (rev 255904) panics with "device hyperv" on XenServer 6.2
On 27-Sep-2013, at 8:20 PM, Roger Pau Monné wrote: > 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. Hi 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. root@fxen1:/usr/src # Regards. @shankerbalan ___ 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 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"
