From owner-freebsd-xen@FreeBSD.ORG Mon Mar 30 14:27:26 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7338D377 for ; Mon, 30 Mar 2015 14:27:26 +0000 (UTC) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D270A12 for ; Mon, 30 Mar 2015 14:27:26 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so118849549iec.0 for ; Mon, 30 Mar 2015 07:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=gfc+raz0qAowKu7pce3wyVLcS8jDuNCoZe913kVwKTw=; b=eZWSemDgcVSEYJVZ0ODIovbxDWERDawwsmOZUDdYrJn8GM5dP3MebV1o22o5lgcD/s Mu+50sW82PZ3ckP2HvrTaQXyIhbdCuKb1kXbrtcpkpy2kImeV1z+2qa8sXHpsUHZpu9M YVTej0s0OhJD2v+mLsygZ/On4xhmtDsZzFmXBY7+Bt1AMKYf1rFoj9WkQ1rW/ZJrOtgr FOPLb9r8ifm+zvBgQ94c72DY/Kn2n+d32zoWIqrTkM22Ff9QyFpccrkjmwDXzLouG7XS sUrz/C+bWzNqg1f3sNVWH3XsUcsBkpTDWtswR0Bvfy0BWbPLoZJ8Lnq0NWtFNvDpsPev R3pg== MIME-Version: 1.0 X-Received: by 10.107.128.213 with SMTP id k82mr1996882ioi.7.1427725645562; Mon, 30 Mar 2015 07:27:25 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Mon, 30 Mar 2015 07:27:25 -0700 (PDT) Reply-To: araujo@FreeBSD.org Date: Mon, 30 Mar 2015 22:27:25 +0800 Message-ID: Subject: Unable to load multiboot kernel. From: Marcelo Araujo To: freebsd-xen@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 14:27:26 -0000 Hi guys, I'm attempting to boot FreeBSD as Dom0 on ThinkPad E550 with an i7-5500U quad-core and 16G of ram. The FreeBSD is in the revision r280848 and Xen is the 4.6-unstable(checkout today). The FreeBSD kernel was built as amd64. So, the problem that I'm facing is that not possible to load multiboot kernel. Right after to load the XEN kernel, its attempt to load the next KERNEL, but I reach out at: sys/boot/i386/libi386/multiboot.c 167 error = elf32_loadfile_raw(filename, dest, result, 1); 168 if (error != 0) { 169 printf( 170 "elf32_loadfile_raw failed: %d unable to load multiboot kernel\n", 171 error); 172 goto out; 173 } I tried to boot at loader using: OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga boot/xen data=0x1e0090+0x7fd20f70 \ OK load /boot/kernel/kernel /boot/kernel/kernel Unable to load /boot/kernel/kernel as a multiboot payload kernel /boot/kernel/kernel text=0x104c6a8 data=0x12dbb8+0x3fb0f0 sysms=[0x8+0x148f98+0x8+0x164832] OK boot And the system is halted. Any idea? Best Regards, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-xen@FreeBSD.ORG Mon Mar 30 15:35:43 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AC42960; Mon, 30 Mar 2015 15:35:43 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF9B6251; Mon, 30 Mar 2015 15:35:42 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,494,1422921600"; d="scan'208";a="247856988" Message-ID: <55196D2F.8040203@citrix.com> Date: Mon, 30 Mar 2015 17:35:11 +0200 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: , Subject: Re: Unable to load multiboot kernel. References: In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 15:35:43 -0000 Hello, El 30/03/15 a les 16.27, Marcelo Araujo ha escrit: > Hi guys, > > I'm attempting to boot FreeBSD as Dom0 on ThinkPad E550 with an i7-5500U > quad-core and 16G of ram. > > The FreeBSD is in the revision r280848 and Xen is the 4.6-unstable(checkout > today). The FreeBSD kernel was built as amd64. > > So, the problem that I'm facing is that not possible to load multiboot > kernel. Right after to load the XEN kernel, its attempt to load the next > KERNEL, but I reach out at: > sys/boot/i386/libi386/multiboot.c > 167 error = elf32_loadfile_raw(filename, dest, result, 1); > 168 if (error != 0) { > 169 printf( > 170 "elf32_loadfile_raw failed: %d unable to load multiboot > kernel\n", > 171 error); > 172 goto out; > 173 } > > I tried to boot at loader using: > OK unload OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 > console=com1,vga > boot/xen data=0x1e0090+0x7fd20f70 \ > OK load /boot/kernel/kernel > /boot/kernel/kernel Unable to load /boot/kernel/kernel as a multiboot > payload kernel > /boot/kernel/kernel text=0x104c6a8 data=0x12dbb8+0x3fb0f0 > sysms=[0x8+0x148f98+0x8+0x164832] > OK boot > > And the system is halted. > > Any idea? That's something new, I've never seen this before. IMHO it seems like arch_readin is failing to load the kernel into memory, but due to the lack of messages I'm not sure. Could you try the patch above? It should make the errors a little bit more chatty. Roger. diff --git a/sys/boot/common/module.c b/sys/boot/common/module.c index b48b493..53ce358 100644 --- a/sys/boot/common/module.c +++ b/sys/boot/common/module.c @@ -380,6 +380,7 @@ file_loadraw(char *name, char *type, int insert) /* We can't load first */ if ((file_findfile(NULL, NULL)) == NULL) { + printf("Can not load a raw file without a kernel\n"); command_errmsg = "can't load file before kernel"; return(NULL); } @@ -387,12 +388,14 @@ file_loadraw(char *name, char *type, int insert) /* locate the file on the load path */ cp = file_search(name, NULL); if (cp == NULL) { + printf("Cannot find %s file\n", name); sprintf(command_errbuf, "can't find '%s'", name); return(NULL); } name = cp; if ((fd = open(name, O_RDONLY)) < 0) { + printf("can't open '%s': %s", name, strerror(errno)); sprintf(command_errbuf, "can't open '%s': %s", name, strerror(errno)); free(name); return(NULL); @@ -404,6 +407,7 @@ file_loadraw(char *name, char *type, int insert) printf("%s ", name); laddr = loadaddr; + printf("Trying to load a RAW file at 0x%lx ", laddr); for (;;) { /* read in 4k chunks; size is not really important */ got = archsw.arch_readin(fd, laddr, 4096); @@ -411,6 +415,7 @@ file_loadraw(char *name, char *type, int insert) break; if (got < 0) { /* error */ sprintf(command_errbuf, "error reading '%s': %s", name, strerror(errno)); + printf("Error reading %s: %s\n", name, strerror(errno)); free(name); close(fd); return(NULL); diff --git a/sys/boot/i386/libi386/multiboot.c b/sys/boot/i386/libi386/multiboot.c index 11c35df..a3f3084 100644 --- a/sys/boot/i386/libi386/multiboot.c +++ b/sys/boot/i386/libi386/multiboot.c @@ -373,7 +373,7 @@ multiboot_obj_loadfile(char *filename, u_int64_t dest, printf( "Unable to load %s as a multiboot payload kernel\n", filename); - return (EFTYPE); + return (EINVAL); } /* Load kernel metadata... */ @@ -382,7 +382,7 @@ multiboot_obj_loadfile(char *filename, u_int64_t dest, if (error) { printf("Unable to load kernel %s metadata error: %d\n", rfp->f_name, error); - return (EFTYPE); + return (EINVAL); } /* From owner-freebsd-xen@FreeBSD.ORG Mon Mar 30 16:18:18 2015 Return-Path: Delivered-To: freebsd-xen@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D9EA462 for ; Mon, 30 Mar 2015 16:18:18 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1471BA13 for ; Mon, 30 Mar 2015 16:18:18 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2UGIHZv015222 for ; Mon, 30 Mar 2015 16:18:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-xen@FreeBSD.org Subject: [Bug 195978] Add vlan support to xen netback Date: Mon, 30 Mar 2015 16:18:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bugs.freebsd.org@zengel.info X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-xen@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 16:18:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195978 --- Comment #2 from Grischa Zengel --- Hi Marcelo, the developers of pfsense won't use a NIC for tagging, unless it supports tagging in hardware. In release 2.2.2 they will get altq support in xn: https://redmine.pfsense.org/issues/4401 Regards, -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-xen@FreeBSD.ORG Mon Mar 30 16:45:18 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52B0B83F for ; Mon, 30 Mar 2015 16:45:18 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 14816E29 for ; Mon, 30 Mar 2015 16:45:18 +0000 (UTC) Received: by iedfl3 with SMTP id fl3so138374028ied.1 for ; Mon, 30 Mar 2015 09:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WmLtgurQxT0mlevSrrzWt/7X5P+IY2+dU3FttfRaiuo=; b=Wcdkmlc4kaOMrAE8+TpVa1R7xBNwzvYXJnnkUasSRTuxmEI0NpmxREr5e3XmUdbNAs X+KbNAHwuII18/F4LzWH0rAnBWKnPHN6ECXuvFJPuFMQ8CByoVDy+q+3zRm9CfhhFxc5 5lJoPAqB/eL/J1NJ57s0ZPnqnx4d73SHsZ1K5JRNo4/4GIrqnPqejsiyLHbAuLVedeaa wbOU2dmWWfJq8ok9BmvXzcgssgUbehzX2IAj3TOXnqRaxDZ8NYRM49/A+xCoXViiJgH1 Q8pe62VkszRga0tOO/RIoumtdUHNK1Zn1THzLxDPS8xJHdS8d7BSckLJ4T5vPWe8Nb7V lllw== MIME-Version: 1.0 X-Received: by 10.50.171.170 with SMTP id av10mr18952814igc.28.1427733917433; Mon, 30 Mar 2015 09:45:17 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Mon, 30 Mar 2015 09:45:17 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <55196D2F.8040203@citrix.com> References: <55196D2F.8040203@citrix.com> Date: Tue, 31 Mar 2015 00:45:17 +0800 Message-ID: Subject: Re: Unable to load multiboot kernel. From: Marcelo Araujo To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-xen@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 16:45:18 -0000 2015-03-30 23:35 GMT+08:00 Roger Pau Monn=C3=A9 : > Hello, > > El 30/03/15 a les 16.27, Marcelo Araujo ha escrit: > > Hi guys, > > > > I'm attempting to boot FreeBSD as Dom0 on ThinkPad E550 with an i7-5500= U > > quad-core and 16G of ram. > > > > The FreeBSD is in the revision r280848 and Xen is the > 4.6-unstable(checkout > > today). The FreeBSD kernel was built as amd64. > > > > So, the problem that I'm facing is that not possible to load multiboot > > kernel. Right after to load the XEN kernel, its attempt to load the ne= xt > > KERNEL, but I reach out at: > > sys/boot/i386/libi386/multiboot.c > > 167 error =3D elf32_loadfile_raw(filename, dest, result, 1); > > 168 if (error !=3D 0) { > > 169 printf( > > 170 "elf32_loadfile_raw failed: %d unable to load multiboot > > kernel\n", > > 171 error); > > 172 goto out; > > 173 } > > > > I tried to boot at loader using: > > OK unload OK load /boot/xen dom0_mem=3D1024M dom0_max_vcpus=3D2 dom0pvh= =3D1 > > console=3Dcom1,vga > > boot/xen data=3D0x1e0090+0x7fd20f70 \ > > OK load /boot/kernel/kernel > > /boot/kernel/kernel Unable to load /boot/kernel/kernel as a multiboot > > payload kernel > > /boot/kernel/kernel text=3D0x104c6a8 data=3D0x12dbb8+0x3fb0f0 > > sysms=3D[0x8+0x148f98+0x8+0x164832] > > OK boot > > > > And the system is halted. > > > > Any idea? > > That's something new, I've never seen this before. IMHO it seems like > arch_readin is failing to load the kernel into memory, but due to the > lack of messages I'm not sure. Could you try the patch above? It should > make the errors a little bit more chatty. > > Roger. > > diff --git a/sys/boot/common/module.c b/sys/boot/common/module.c > index b48b493..53ce358 100644 > --- a/sys/boot/common/module.c > +++ b/sys/boot/common/module.c > @@ -380,6 +380,7 @@ file_loadraw(char *name, char *type, int insert) > > /* We can't load first */ > if ((file_findfile(NULL, NULL)) =3D=3D NULL) { > + printf("Can not load a raw file without a kernel\n"); > command_errmsg =3D "can't load file before kernel"; > return(NULL); > } > @@ -387,12 +388,14 @@ file_loadraw(char *name, char *type, int insert) > /* locate the file on the load path */ > cp =3D file_search(name, NULL); > if (cp =3D=3D NULL) { > + printf("Cannot find %s file\n", name); > sprintf(command_errbuf, "can't find '%s'", name); > return(NULL); > } > name =3D cp; > > if ((fd =3D open(name, O_RDONLY)) < 0) { > + printf("can't open '%s': %s", name, strerror(errno)); > sprintf(command_errbuf, "can't open '%s': %s", name, > strerror(errno)); > free(name); > return(NULL); > @@ -404,6 +407,7 @@ file_loadraw(char *name, char *type, int insert) > printf("%s ", name); > > laddr =3D loadaddr; > + printf("Trying to load a RAW file at 0x%lx ", laddr); > for (;;) { > /* read in 4k chunks; size is not really important */ > got =3D archsw.arch_readin(fd, laddr, 4096); > @@ -411,6 +415,7 @@ file_loadraw(char *name, char *type, int insert) > break; > if (got < 0) { /* error */ > sprintf(command_errbuf, "error reading '%s': %s", name, > strerror(errno)); > + printf("Error reading %s: %s\n", name, strerror(errno)); > free(name); > close(fd); > return(NULL); > diff --git a/sys/boot/i386/libi386/multiboot.c > b/sys/boot/i386/libi386/multiboot.c > index 11c35df..a3f3084 100644 > --- a/sys/boot/i386/libi386/multiboot.c > +++ b/sys/boot/i386/libi386/multiboot.c > @@ -373,7 +373,7 @@ multiboot_obj_loadfile(char *filename, u_int64_t dest= , > printf( > "Unable to load %s as a multiboot payload > kernel\n", > filename); > - return (EFTYPE); > + return (EINVAL); > } > > /* Load kernel metadata... */ > @@ -382,7 +382,7 @@ multiboot_obj_loadfile(char *filename, u_int64_t dest= , > if (error) { > printf("Unable to load kernel %s metadata error: > %d\n", > rfp->f_name, error); > - return (EFTYPE); > + return (EINVAL); > } > > /* > > > Hello Roger, Thanks for the prompt reply and for the patch. I made a test and now we have a bit more of information. Seems the problem is because the kernel is too large. OK load /boot/kernel/kernel /boot/kernel/kernel Trying to load a RAW file at 0x80001000 Error reading /boot/kernel/kernel: file too large Unable to load /boot/kernel/kernel as a multiboot payload kernel can't load file '/boot/kernel/kernel': invalid argument. Here is the size of my kernel: root@e550:/usr/src/sys/boot # du /boot/kernel/kernel 12885 /boot/kernel/kernel Best Regards, --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-xen@FreeBSD.ORG Mon Mar 30 17:20:21 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 148EBC5E; Mon, 30 Mar 2015 17:20:21 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 98F91303; Mon, 30 Mar 2015 17:20:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,494,1422921600"; d="scan'208";a="247897785" Message-ID: <551985BB.6050706@citrix.com> Date: Mon, 30 Mar 2015 19:19:55 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Subject: Re: Unable to load multiboot kernel. References: <55196D2F.8040203@citrix.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: freebsd-xen@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 17:20:21 -0000 Hello, El 30/03/15 a les 18.45, Marcelo Araujo ha escrit: > Hello Roger, > > Thanks for the prompt reply and for the patch. > > I made a test and now we have a bit more of information. Seems the problem > is because the kernel is too large. > > OK load /boot/kernel/kernel > /boot/kernel/kernel Trying to load a RAW file at 0x80001000 Error reading > /boot/kernel/kernel: file too large > Unable to load /boot/kernel/kernel as a multiboot payload kernel > can't load file '/boot/kernel/kernel': invalid argument. > > Here is the size of my kernel: > root@e550:/usr/src/sys/boot # du /boot/kernel/kernel > 12885 /boot/kernel/kernel Mmmm, that's smaller than mine and should load without problems: # du /boot/kernel/kernel 21537 /boot/kernel/kernel I think the problem might be that your BIOS is not correctly reporting the extended memory size, or that the loader is not fetching it properly. Can you try the following patch to see which values you get? On one of my boxes that is able to load FreeBSD/Xen I get: bios_extmem: 0xd75d8000 memtop_copyin: 0xd76d8000 memtop: 0xd76d8000 You can apply the patch on top of the previous one, or standalone, as you wish. Roger. --- diff --git a/sys/boot/i386/libi386/i386_copy.c b/sys/boot/i386/libi386/i386_copy.c index 3c05241..4d62282 100644 --- a/sys/boot/i386/libi386/i386_copy.c +++ b/sys/boot/i386/libi386/i386_copy.c @@ -67,6 +67,8 @@ i386_readin(const int fd, vm_offset_t dest, const size_t len) { if (dest + len >= memtop_copyin) { + printf("bios_extmem: 0x%x memtop_copyin: 0x%x memtop: 0x%x\n", + bios_extmem, memtop_copyin, memtop); errno = EFBIG; return(-1); } From owner-freebsd-xen@FreeBSD.ORG Tue Mar 31 00:54:56 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0F611A0 for ; Tue, 31 Mar 2015 00:54:55 +0000 (UTC) Received: from os-mail-4.tamu.edu (os-mail-4.tamu.edu [165.91.23.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-relay.tamu.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE8AF392 for ; Tue, 31 Mar 2015 00:54:55 +0000 (UTC) X-TAMU-Auth-ID: None X-TAMU-SenderIP: 165.91.22.240 Received: from exchange.tamu.edu (exch-2p-snat-pool.tamu.edu [165.91.22.240]) by os-mail-4.itio.tamu.edu (8.14.7/8.14.7) with ESMTP id t2UNqH34041346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Mar 2015 18:52:17 -0500 Received: from MB03.ads.tamu.edu ([169.254.3.105]) by caex01.ads.tamu.edu ([128.194.147.20]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 18:52:16 -0500 From: Andrew Daugherity To: =?Windows-1252?Q?Roger_Pau_Monn=E9?= Subject: Re: Poor performance with FreeBSD 10.1 under Xen 4.2 Thread-Topic: Poor performance with FreeBSD 10.1 under Xen 4.2 Thread-Index: AQHQaOOfinlni718o0SDQUrW328qGJ0yNL4AgAPWZYA= Date: Mon, 30 Mar 2015 23:52:16 +0000 Message-ID: <57429F3F-8CC9-4C4F-86DF-3E63C5853B01@tamu.edu> References: <115BE54D-078A-4C45-8904-861DAB316C03@tamu.edu> <5516A998.10206@citrix.com> In-Reply-To: <5516A998.10206@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.194.89.247] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-30_04:2015-03-30,2015-03-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=4.95264940170159e-12 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999586866343301 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.999586866343301 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.999586866343301 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503300212 Cc: "freebsd-xen@freebsd.org" X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 00:54:56 -0000 > On Mar 28, 2015, at 8:16 AM, Roger Pau Monn=E9 wro= te: >=20 > Hello, >=20 > Thanks for the detailed description of the issue. I've reproduced your > benchmarks and with the hardware I've used (Core i3-5010U) I'm not able > to see this performance issue, below are the figures in my case: > [...] >=20 > I'm Ccing feld because IIRC he found something similar on one of his > boxes, that also had VTx but no EPT (just like yours). Would it be > possible for you to try the same set of tests on a different hardware? I think you're on to something. I copied this FreeBSD 10.1 VM to a system = running the same version of Xen (and same SLES in the Dom0), but with an Op= teron 2360SE CPU (which has both SVM and NPT), and it is *much* faster (and= feels more responsive too): Forked, executed and destroyed 5000 processes in 5.216613 seconds. [Subsequent runs are consistently between 5.1 and 5.5 seconds.] sssd configure: 22.210u 8.751s 0:30.39 101.8% 4915+236k 0+300io 31pf+0w sssd build: 176.556u 78.846s 2:15.77 188.1% 5534+217k 49+44io 8pf+0w I'll run some more benchmarks, but I don't recall Linux VMs being noticeabl= y different in speed between the Opteron and the Xeon systems -- I'm pretty= sure it's not a case of a raw CPU power advantage. > Also, if even FreeBSD 10.1 compiled without XENHVM shows this issue it > means there's something in the generic code that doesn't work well when > running virtualized on this specific hardware, but I'm afraid figuring > it out is not trivial. One place to start would be asking on > freebsd-hackers and freebsd-virt. I suppose this performance delta with presence of EPT/NPT vs. lack thereof = means it's time to take it to those lists? My next step will be to test 10= .1 under KVM on the Xeon to confirm whether it's a Xen issue or strictly EP= T. Thanks for the tips! -Andrew From owner-freebsd-xen@FreeBSD.ORG Tue Mar 31 03:26:57 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00D5D71E for ; Tue, 31 Mar 2015 03:26:56 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B5A2E8CC for ; Tue, 31 Mar 2015 03:26:56 +0000 (UTC) Received: by igcau2 with SMTP id au2so4943356igc.1 for ; Mon, 30 Mar 2015 20:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Tt/MaJl8TtSZZ1/d/jauBMM3ufG5Qyf5XNSvh+MMZJM=; b=mFZzF7jDBaWWgv3sF0MJb9JIkoDkFVBEOvVjwpNwzuy6uuQKDCGa6FIQcoPD6Nrjnb cs4H8kAytGX6c4VR0ax1LZbzRNeEdIY7qD4X+wDdueLidlkRYtG7zNqvXWiN0H171Mb/ 0BxzxrR9RfWXdBU+XTdMQWnw4z2zrI+LZ76geFbZIvSHRGbAynyLQmHsV1hxMqHj0pB3 bH9o0elkYPndebu6uehJGTqbV5Q4GYDYLM3Zkd+Bb624WhGfjYqPCgD/XFwvcX8zHqkQ qqJEAZGmp0CtDUzKGucH/rL80r4MIYSOr8O7dnL1iG2ChGD1TuNPiEIpKqHahGlLjRdG v1zQ== MIME-Version: 1.0 X-Received: by 10.107.46.155 with SMTP id u27mr52080038iou.87.1427772415704; Mon, 30 Mar 2015 20:26:55 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Mon, 30 Mar 2015 20:26:55 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <551985BB.6050706@citrix.com> References: <55196D2F.8040203@citrix.com> <551985BB.6050706@citrix.com> Date: Tue, 31 Mar 2015 11:26:55 +0800 Message-ID: Subject: Re: Unable to load multiboot kernel. From: Marcelo Araujo To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-xen X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 03:26:57 -0000 2015-03-31 1:19 GMT+08:00 Roger Pau Monn=C3=A9 : > Hello, > > El 30/03/15 a les 18.45, Marcelo Araujo ha escrit: > > Hello Roger, > > > > Thanks for the prompt reply and for the patch. > > > > I made a test and now we have a bit more of information. Seems the > problem > > is because the kernel is too large. > > > > OK load /boot/kernel/kernel > > /boot/kernel/kernel Trying to load a RAW file at 0x80001000 Error readi= ng > > /boot/kernel/kernel: file too large > > Unable to load /boot/kernel/kernel as a multiboot payload kernel > > can't load file '/boot/kernel/kernel': invalid argument. > > > > Here is the size of my kernel: > > root@e550:/usr/src/sys/boot # du /boot/kernel/kernel > > 12885 /boot/kernel/kernel > > Mmmm, that's smaller than mine and should load without problems: > > # du /boot/kernel/kernel > 21537 /boot/kernel/kernel > > I think the problem might be that your BIOS is not correctly reporting > the extended memory size, or that the loader is not fetching it > properly. Can you try the following patch to see which values you get? > On one of my boxes that is able to load FreeBSD/Xen I get: > > bios_extmem: 0xd75d8000 memtop_copyin: 0xd76d8000 memtop: 0xd76d8000 > > You can apply the patch on top of the previous one, or standalone, as > you wish. > > Roger. > > --- > diff --git a/sys/boot/i386/libi386/i386_copy.c > b/sys/boot/i386/libi386/i386_copy.c > index 3c05241..4d62282 100644 > --- a/sys/boot/i386/libi386/i386_copy.c > +++ b/sys/boot/i386/libi386/i386_copy.c > @@ -67,6 +67,8 @@ i386_readin(const int fd, vm_offset_t dest, const size_= t > len) > { > > if (dest + len >=3D memtop_copyin) { > + printf("bios_extmem: 0x%x memtop_copyin: 0x%x memtop: 0x%x\n", > + bios_extmem, memtop_copyin, memtop); > errno =3D EFBIG; > return(-1); > } > > Hi Roger, Yes, seems my BIOS is not correctly reporting the extended memory size. The value that I got from my box is: bios_extmem: 0xff00000 memtop_copyin: 0x10000000 memtop: 0x10000000 I did check my BIOS if there is any suspicious options that may mess up with the memory, but I didn't find nothing. I will check if there is any new BIOS version. Do you have any other idea? Best Regards, --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-xen@FreeBSD.ORG Tue Mar 31 06:15:08 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC64FAB2; Tue, 31 Mar 2015 06:15:08 +0000 (UTC) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E41EC28; Tue, 31 Mar 2015 06:15:08 +0000 (UTC) Received: by ignm3 with SMTP id m3so6648140ign.0; Mon, 30 Mar 2015 23:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QBR9DA6XLZnKoWFrNZu+WNp98/rRIKhHhMVvod353fE=; b=MnqSgujc9fSlprQVzG0LpVPAcC0aOaxnd65drkcfOH5QXchjBg3ggYARkTONd/13Op FSQgChVU3BCblAnII4YKm6dX10a+YTaiklMaxFi/R4mBBm9jZvdo8PGkplWkWkRLqlZn cyCqR1FAG9yVNpEd92s90BEEj+flgbZkFEgMrf43FRRUdiv6kXHboSmD8+X5vi8xkKbf eRqZ7dAztse00IdgHniNL7xG93H0R9NweXKLpb/RA3qtUD8+GRWlZf66SeznOZDce/6J XMnKZu8hx6EyRdt+XtHSxa3pKb7B22LnYhuwA1H0mHSyS/MaxhHy5UMLF4SY332TkDU8 1Ejw== MIME-Version: 1.0 X-Received: by 10.107.128.213 with SMTP id k82mr6816287ioi.7.1427782507835; Mon, 30 Mar 2015 23:15:07 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Mon, 30 Mar 2015 23:15:07 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: References: <55196D2F.8040203@citrix.com> <551985BB.6050706@citrix.com> Date: Tue, 31 Mar 2015 14:15:07 +0800 Message-ID: Subject: Re: Unable to load multiboot kernel. From: Marcelo Araujo To: Marcelo Souza Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-xen X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 06:15:08 -0000 2015-03-31 11:26 GMT+08:00 Marcelo Araujo : > >> > Hi Roger, > > Yes, seems my BIOS is not correctly reporting the extended memory size. > The value that I got from my box is: > > bios_extmem: 0xff00000 memtop_copyin: 0x10000000 memtop: 0x10000000 > > I did check my BIOS if there is any suspicious options that may mess up > with the memory, but I didn't find nothing. I will check if there is any > new BIOS version. > > Do you have any other idea? > > Best Regards, > > Hi Roger, Just to inform you, I updated the BIOS to the latest version and everything is the same with the same values for bios_extmem, memtop_copyin and memtop. Best Regards, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-xen@FreeBSD.ORG Tue Mar 31 07:07:23 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2D07A17; Tue, 31 Mar 2015 07:07:23 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4248F173; Tue, 31 Mar 2015 07:07:22 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,499,1422921600"; d="scan'208";a="248072925" Message-ID: <551A4789.6070508@citrix.com> Date: Tue, 31 Mar 2015 09:06:49 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Subject: Re: Unable to load multiboot kernel. References: <55196D2F.8040203@citrix.com> <551985BB.6050706@citrix.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: freebsd-xen X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 07:07:23 -0000 Hello, El 31/03/15 a les 5.26, Marcelo Araujo ha escrit: > Hi Roger, > > Yes, seems my BIOS is not correctly reporting the extended memory size. > The value that I got from my box is: > > bios_extmem: 0xff00000 memtop_copyin: 0x10000000 memtop: 0x10000000 > > I did check my BIOS if there is any suspicious options that may mess up > with the memory, but I didn't find nothing. I will check if there is any > new BIOS version. > > Do you have any other idea? Can you boot a bare metal kernel with boot_verbose="YES" and copy the memory map reported by FreeBSD when booting? There's also a recent change to biosmem.c which touched extended memory detection, r279222. Could you try to revert that commit and see if it makes any difference? Roger. From owner-freebsd-xen@FreeBSD.ORG Tue Mar 31 09:09:17 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20F3E417 for ; Tue, 31 Mar 2015 09:09:17 +0000 (UTC) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D501B166 for ; Tue, 31 Mar 2015 09:09:16 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so11674766igb.1 for ; Tue, 31 Mar 2015 02:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QJRjCAZsJ/wt4eUAifWV0yb0+0aar2vVegMLXaxTxPI=; b=E+DKPNArBxJ2STJz8Svhkk+lthlUC1xsZ6SURJEJIx5SR5OxS+Bys8Lb2pqEHw4vEc a5FJXNPGS2eosisoOy8I4PkAyxoTp2UJ/04PcuOA3Sl8DAZrTaNZZkzPE7aWyw9Ex271 ricryFfJRSzjtKbbJs/g68UBYbcilFM4kjl1fPWHILmuuAFQw4Wx5d1Q26OE51eqHtly JGhYMx6tg0wqMJ7S2yWSP8VTDxX+V30ZIz5DKR20kF5YVOmGzjUBEaVJm0Dfm9qkhdM+ d/vLbW2jSfb2LXqChf9ddUjgZ9oJJcXQ2RFptnbRKYdsOXLw5hpXpERo4bJWxd1bmBj7 F0qA== MIME-Version: 1.0 X-Received: by 10.43.38.144 with SMTP id ti16mr66014988icb.26.1427792956265; Tue, 31 Mar 2015 02:09:16 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Tue, 31 Mar 2015 02:09:16 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <551A4789.6070508@citrix.com> References: <55196D2F.8040203@citrix.com> <551985BB.6050706@citrix.com> <551A4789.6070508@citrix.com> Date: Tue, 31 Mar 2015 17:09:16 +0800 Message-ID: Subject: Re: Unable to load multiboot kernel. From: Marcelo Araujo To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-xen X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 09:09:17 -0000 2015-03-31 15:06 GMT+08:00 Roger Pau Monn=C3=A9 : > Hello, > > El 31/03/15 a les 5.26, Marcelo Araujo ha escrit: > > Hi Roger, > > > > Yes, seems my BIOS is not correctly reporting the extended memory size. > > The value that I got from my box is: > > > > bios_extmem: 0xff00000 memtop_copyin: 0x10000000 memtop: 0x10000000 > > > > I did check my BIOS if there is any suspicious options that may mess up > > with the memory, but I didn't find nothing. I will check if there is an= y > > new BIOS version. > > > > Do you have any other idea? > > Can you boot a bare metal kernel with boot_verbose=3D"YES" and copy the > memory map reported by FreeBSD when booting? > > There's also a recent change to biosmem.c which touched extended memory > detection, r279222. Could you try to revert that commit and see if it > makes any difference? > > Roger. > Hi, Here is the memory map from boot: real memory =3D 17179869184 (16384 MB) Physical memory chunk(s): 0x0000000000010000 - 0x0000000000098fff, 561152 bytes (137 pages) 0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) 0x0000000001b32000 - 0x000000000fffffff, 239919104 bytes (58574 pages) 0x000000001000b000 - 0x00000000a069dfff, 2422812672 bytes (591507 pages) 0x0000000100000000 - 0x0000000432df2fff, 13738389504 bytes (3354099 pages) avail memory =3D 16297324544 (15542 MB) I reverted everything to r279220 and rebuilt world/kernel, doesn't make any difference. I'm gonna try to make some more debugs tonight, in case you want me test anything else, let me know. Best Regards, --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-xen@FreeBSD.ORG Tue Mar 31 19:06:01 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 77B07D1E; Tue, 31 Mar 2015 19:06:01 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 17DAE698; Tue, 31 Mar 2015 19:06:00 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,502,1422921600"; d="scan'208";a="248303867" Message-ID: <551AF00F.5030001@citrix.com> Date: Tue, 31 Mar 2015 21:05:51 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Subject: Re: Unable to load multiboot kernel. References: <55196D2F.8040203@citrix.com> <551985BB.6050706@citrix.com> <551A4789.6070508@citrix.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: freebsd-xen X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 19:06:01 -0000 Hello, El 31/03/15 a les 11.09, Marcelo Araujo ha escrit: > I reverted everything to r279220 and rebuilt world/kernel, doesn't make any > difference. > I'm gonna try to make some more debugs tonight, in case you want me test > anything else, let me know. I've finally found were the issue comes from, and it is due to a bug in our version of nm, which is used to build the Xen kernel. You can apply the following patch [1] to the FreeBSD source tree, rebuild and reinstall nm and then recompile the Xen kernel. The new one should work without problems I think. Roger. [1] http://pastebin.com/raw.php?i=QbZ9exai From owner-freebsd-xen@FreeBSD.ORG Wed Apr 1 04:25:48 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5AF631F4 for ; Wed, 1 Apr 2015 04:25:48 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AD0BF4A for ; Wed, 1 Apr 2015 04:25:48 +0000 (UTC) Received: by igbqf9 with SMTP id qf9so36041941igb.1 for ; Tue, 31 Mar 2015 21:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JOWI2xLzJvqO6eFOF5luDeWc+D2XrxxBvpsK2R52k2o=; b=s+BAfGoU7JX4G388WQWVCa8uF+zaIrRei4or7gAn2JeMbN0+o/8G62eN+Kpa/DHOzo 33A+iq3FF1wr5FhfHteqGSXpQkdU1tpmIBL7RCt9Oa0V1bRMpNrN/p3uxpKFSUcQ1uFZ meme5iYd1/4oUd+qw68x6NedMp41Mn7dEt8FXjx5airF4t8zR0La2TdLeJqcc47LyAit 0EnjWHavYmWiJ2Ljrm4l5vYZ9V1xk8s0Nxi4R6x4mKt4SPN/fCdEVrjr52OX6sFloz91 rmbWkcTYg1I7j2W1Me9JEIxXjW/jk2h4lGF1Kh3qdpfz75B5mqZ76azQ5S7dUOovALTG f9ag== MIME-Version: 1.0 X-Received: by 10.107.128.213 with SMTP id k82mr14157910ioi.7.1427862347509; Tue, 31 Mar 2015 21:25:47 -0700 (PDT) Received: by 10.64.59.138 with HTTP; Tue, 31 Mar 2015 21:25:47 -0700 (PDT) Reply-To: araujo@FreeBSD.org In-Reply-To: <551AF00F.5030001@citrix.com> References: <55196D2F.8040203@citrix.com> <551985BB.6050706@citrix.com> <551A4789.6070508@citrix.com> <551AF00F.5030001@citrix.com> Date: Wed, 1 Apr 2015 12:25:47 +0800 Message-ID: Subject: Re: Unable to load multiboot kernel. From: Marcelo Araujo To: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-xen X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 04:25:48 -0000 2015-04-01 3:05 GMT+08:00 Roger Pau Monn=C3=A9 : > Hello, > > El 31/03/15 a les 11.09, Marcelo Araujo ha escrit: > > I reverted everything to r279220 and rebuilt world/kernel, doesn't make > any > > difference. > > I'm gonna try to make some more debugs tonight, in case you want me tes= t > > anything else, let me know. > > I've finally found were the issue comes from, and it is due to a bug in > our version of nm, which is used to build the Xen kernel. You can apply > the following patch [1] to the FreeBSD source tree, rebuild and > reinstall nm and then recompile the Xen kernel. The new one should work > without problems I think. > > Roger. > > [1] http://pastebin.com/raw.php?i=3DQbZ9exai > > Hello Roger, It works just fine! Thanks for the patch. root@e550:/z/xen_vm # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 4096 4 r----- 66.0 FreeBSDSrc 1 2048 2 -b---- 14.6 So, will you commit it? Do you need any other test or information? Best Regards, --=20 --=20 Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org \/ \ ^ Power To Server. .\. /_) From owner-freebsd-xen@FreeBSD.ORG Wed Apr 1 07:59:30 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 514668EE; Wed, 1 Apr 2015 07:59:30 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE6D5145; Wed, 1 Apr 2015 07:59:29 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="250235396" Message-ID: <551BA558.4090905@citrix.com> Date: Wed, 1 Apr 2015 09:59:20 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Subject: Re: Unable to load multiboot kernel. References: <55196D2F.8040203@citrix.com> <551985BB.6050706@citrix.com> <551A4789.6070508@citrix.com> <551AF00F.5030001@citrix.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Cc: freebsd-xen X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 07:59:30 -0000 El 01/04/15 a les 6.25, Marcelo Araujo ha escrit: > Hello Roger, > > It works just fine! Thanks for the patch. > root@e550:/z/xen_vm # xl list > Name ID Mem VCPUs State Time(s) > Domain-0 0 4096 4 r----- > 66.0 > FreeBSDSrc 1 2048 2 -b---- > 14.6 > > So, will you commit it? > Do you need any other test or information? Ed Maste already committed it as part of r280932 ;). Roger. From owner-freebsd-xen@FreeBSD.ORG Wed Apr 1 22:51:09 2015 Return-Path: Delivered-To: freebsd-xen@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D2DE1F3 for ; Wed, 1 Apr 2015 22:51:09 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 03A038BD for ; Wed, 1 Apr 2015 22:51:09 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t31Mp8pP015289 for ; Wed, 1 Apr 2015 22:51:08 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-xen@FreeBSD.org Subject: [Bug 195978] Add vlan support to xen netfront Date: Wed, 01 Apr 2015 22:51:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bugs.freebsd.org@zengel.info X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-xen@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:51:09 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195978 Grischa Zengel changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Add vlan support to xen |Add vlan support to xen |netback |netfront -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-xen@FreeBSD.ORG Thu Apr 2 16:23:41 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9EA4E07 for ; Thu, 2 Apr 2015 16:23:41 +0000 (UTC) Received: from smtpproxy14.qq.com (smtpbg299.qq.com [184.105.67.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A69A6D2D for ; Thu, 2 Apr 2015 16:23:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201307; t=1427991818; bh=mW20hpk3REPEVTrcypnMeYS7Szp+vC74nhw/YBLqcl0=; h=X-QQ-FEAT:X-QQ-SSF:X-HAS-ATTACH:X-QQ-BUSINESS-ORIGIN: X-Originating-IP:X-QQ-STYLE:X-QQ-mid:From:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Date: X-Priority:Message-ID:X-QQ-MIME:X-Mailer:X-QQ-Mailer:X-QQ-SENDSIZE: X-QQ-FName:X-QQ-LocalIP; b=GnjbPukVDPWAvcfbcDVNsPNzV14Tk+d5JGDwyFhULp+/vK5m/CAf2eXa6WKDd3eH2 NFe5o1C/+m6tUIutvCoedYSBVa7OWy31+UvHgOxfVuZpN6KMkMSi0ZMjxXNsllIZxj JZcU9ATE5i+LPXzKDSrOENqlJhlQW6y1401u7qys= X-QQ-FEAT: OcN/YEKeaRVlzDplXU0VViYqIjymtYRRcil3nVjM9wCDNvZUkYFwu4nTj4fHL LgI/ejBO9O8GInpNp+/Zj6oqiDyhbvVFTfWjtf54n03ry81oJX+zSbDtvB9cwlmrvggALFk NrwDsFTuW3bIHR4853YfLWd+DcmDWzKTRwL21ZqByE3xbNmakhPx/4QVaxRJFijNMZjQYNS VlEQIhRRZBony2UqIrMsP X-QQ-SSF: 000000000000008000000000000000Z X-HAS-ATTACH: no X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 221.217.141.45 X-QQ-STYLE: X-QQ-mid: webmail514t1427991807t5691880 From: "=?utf-8?B?R2F2aW4gTXU=?=" To: "=?utf-8?B?ZnJlZWJzZC14ZW4=?=" Subject: failed to boot FreeBSD 11-CURRENT as Xen Dom0 Mime-Version: 1.0 Date: Fri, 3 Apr 2015 00:23:27 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 X-QQ-FName: 829B2543185D440980EACD0C39640112 X-QQ-LocalIP: 58.250.134.100 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:23:42 -0000 VG9kYXkgSSB0cmllZCBYZW4gRG9tMCBvbiBvbmUgU3VwZXJNaWNybyBYOVNSVy1GIG1hY2hp bmUsIGJ1dCBpdCBmYWlsZWQgdG8gYm9vdHVwLiBJcyB0aGVyZSBhbnlib2R5IGNhbiBoZWxw PyB0aGFua3MuDQoNCihYRU4pIFhlbiB2ZXJzaW9uIDQuNi11bnN0YWJsZSAocm9vdEApIChn Y2M0NyAoRnJlZUJTRCBQb3J0cyBDb2xsZWN0aW9uKSA0LjcuNCkgZGVidWc9eSBGcmkgQXBy ICAzIDAwOjA0OjUwIENTVCAyMDE1DQooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0OiBUdWUgTWFy IDE3IDE1OjExOjMzIDIwMTUgKzAxMDAgZ2l0OjNhMjhmNzYNCihYRU4pIEJvb3Rsb2FkZXI6 IEZyZWVCU0QgTG9hZGVyDQooWEVOKSBDb21tYW5kIGxpbmU6IGRvbTBfbWVtPTgxOTJNIGRv bTBfbWF4X3ZjcHVzPTQgZG9tMHB2aD0xIGNvbTI9MTE1MjAwLDhuMSwweDJmOCBndWVzdF9s b2dsdmwgY29uc29sZT1jb20yLHZnYSBpb21tdT1kZWJ1Zw0KKFhFTikgVmlkZW8gaW5mb3Jt YXRpb246DQooWEVOKSAgVkdBIGlzIHRleHQgbW9kZSA4MHgyNSwgZm9udCA4eDE2DQooWEVO KSAgVkJFL0REQyBtZXRob2RzOiBub25lOyBFRElEIHRyYW5zZmVyIHRpbWU6IDAgc2Vjb25k cw0KKFhFTikgIEVESUQgaW5mbyBub3QgcmV0cmlldmVkIGJlY2F1c2Ugbm8gRERDIHJldHJp ZXZhbCBtZXRob2QgZGV0ZWN0ZWQNCihYRU4pIERpc2MgaW5mb3JtYXRpb246ICAgICAgICAg ICAgICAgICAgICB8DQooWEVOKSAgRm91bmQgMSBNQlIgc2lnbmF0dXJlc10gICAgICAgICAg ICAgfA0KKFhFTikgIEZvdW5kIDEgRUREIGluZm9ybWF0aW9uIHN0cnVjdHVyZXMgIHwNCihY RU4pIFhlbi1lODIwIFJBTSBtYXA6ZXIgcHJvbXB0ICAgICAgICAgICB8DQooWEVOKSAgMDAw MDAwMDAwMDAwMDAwMCAtIDAwMDAwMDAwMDAwOWFjMDAgKHVzYWJsZSkNCihYRU4pICAwMDAw MDAwMDAwMDlhYzAwIC0gMDAwMDAwMDAwMDBhMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAw MDAwMDAwMDBlMDAwMCAtIDAwMDAwMDAwMDAxMDAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAw MDAwMDAwMDAxMDAwMDAgLSAwMDAwMDAwMDdkZGEwMDAwICh1c2FibGUpDQooWEVOKSAgMDAw MDAwMDA3ZGRhMDAwMCAtIDAwMDAwMDAwN2RkZGYwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAw MDAwMDAwN2RkZGYwMDAgLSAwMDAwMDAwMDdkZWU2MDAwIChBQ1BJIGRhdGEpDQooWEVOKSAg MDAwMDAwMDA3ZGVlNjAwMCAtIDAwMDAwMDAwN2UwZjEwMDAgKEFDUEkgTlZTKQ0KKFhFTikg IDAwMDAwMDAwN2UwZjEwMDAgLSAwMDAwMDAwMDdmMzZiMDAwIChyZXNlcnZlZCkNCihYRU4p ICAwMDAwMDAwMDdmMzZiMDAwIC0gMDAwMDAwMDA3ZjgwMDAwMCAoQUNQSSBOVlMpDQooWEVO KSAgMDAwMDAwMDA4MDAwMDAwMCAtIDAwMDAwMDAwOTAwMDAwMDAgKHJlc2VydmVkKQ0KKFhF TikgIDAwMDAwMDAwZmVkMWMwMDAgLSAwMDAwMDAwMGZlZDQwMDAwIChyZXNlcnZlZCkNCihY RU4pICAwMDAwMDAwMGZmMDAwMDAwIC0gMDAwMDAwMDEwMDAwMDAwMCAocmVzZXJ2ZWQpDQoo WEVOKSAgMDAwMDAwMDEwMDAwMDAwMCAtIDAwMDAwMDA0ODAwMDAwMDAgKHVzYWJsZSlSDQoo WEVOKSBBQ1BJOiBSU0RQIDAwMEYwNEEwLCAwMDI0IChyMiBTVVBFUk0pZUJTRC4NCihYRU4p IEFDUEk6IFhTRFQgN0RFMTMwODgsIDAwOEMgKHIxIFNVUEVSTSBTTUNJLS1NQiAgICAgICAg MSBBTUkgICAgIDEwMDEzKQ0KKFhFTikgQUNQSTogRkFDUCA3REUxRDhGMCwgMDBGNCAocjQg U1VQRVJNIFNNQ0ktLU1CICAgICAgICAxIEFNSSAgICAgMTAwMTMpDQooWEVOKSBBQ1BJOiBE U0RUIDdERTEzMUEwLCBBNzRBIChyMiBTVVBFUk0gU01DSS0tTUIgICAgICAgIDAgSU5UTCAy MDA5MTExMikNCihYRU4pIEFDUEk6IEZBQ1MgN0UwRTgwODAsIDAwNDAsICdoZWxwJyBmb3Ig bW9yZSBkZXRhaWxlZCBoZWxwLg0KKFhFTikgQUNQSTogQVBJQyA3REUxRDlFOCwgMDEwMCAo cjMgICAgICAgICAgICAgICAgICAgICAgICAxIEFNSSAgICAgMTAwMTMpDQooWEVOKSBBQ1BJ OiBGUERUIDdERTFEQUU4LCAwMDQ0IChyMSAgICAgICAgICAgICAgICAgICAgICAgIDEgQU1J ICAgICAxMDAxMykNCihYRU4pIEFDUEk6IEhQRVQgN0RFMURCMzAsIDAwMzggKHIxIFNVUEVS TSBTTUNJLS1NQiAgICAgICAgMSBBTUkuICAgICAgICA1KQ0KKFhFTikgQUNQSTogUFJBRCA3 REUxREI2OCwgMDBCRSAocjIgUFJBRElEICBQUkFEVElEICAgICAgICAxIE1TRlQgIDQwMDAw MDApDQooWEVOKSBBQ1BJOiBTUE1JIDdERTFEQzI4LCAwMDQwIChyNSBBIE0gSSAgIE9FTVNQ TUkgICAgICAgIDAgQU1JLiAgICAgICAgMCkNCihYRU4pIEFDUEk6IFNTRFQgN0RFMURDNjgs IEM3QUU4IChyMiAgSU5URUwgICAgQ3B1UG0gICAgIDQwMDAgSU5UTCAyMDA5MTExMikNCihY RU4pIEFDUEk6IEVJTkogN0RFRTU3NTAsIDAxMzAgKHIxICAgIEFNSSBBTUkgRUlOSiAgICAg ICAgMCAgICAgICAgICAgICAwKQ0KKFhFTikgQUNQSTogRVJTVCA3REVFNTg4MCwgMDIzMCAo cjEgIEFNSUVSIEFNSSBFUlNUICAgICAgICAwICAgICAgICAgICAgIDApDQooWEVOKSBBQ1BJ OiBIRVNUIDdERUU1QUIwLCAwMEE4IChyMSAgICBBTUkgQU1JIEhFU1QgICAgICAgIDAgICAg ICAgICAgICAgMCkNCihYRU4pIEFDUEk6IEJFUlQgN0RFRTVCNTgsIDAwMzAgKHIxICAgIEFN SSBBTUkgQkVSVCAgICAgICAgMCAgICAgICAgICAgICAwKQ0KKFhFTikgQUNQSTogRE1BUiA3 REVFNUI4OCwgMDBDNCAocjEgQSBNIEkgICBPRU1ETUFSICAgICAgICAxIElOVEwgICAgICAg IDEpDQooWEVOKSBBQ1BJOiBNQ0ZHIDdERUU1QzUwLCAwMDNDIChyMSBTVVBFUk0gU01DSS0t TUIgICAgICAgIDEgTVNGVCAgICAgICA5NykNCihYRU4pIFN5c3RlbSBSQU06IDE2MzQ5TUIg KDE2NzQxNjA4a0IpDQooWEVOKSBObyBOVU1BIGNvbmZpZ3VyYXRpb24gZm91bmQNCihYRU4p IEZha2luZyBhIG5vZGUgYXQgMDAwMDAwMDAwMDAwMDAwMC0wMDAwMDAwNDgwMDAwMDAwDQoo WEVOKSBEb21haW4gaGVhcCBpbml0aWFsaXNlZA0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxl IGF0IDAwMGZkOTUwDQooWEVOKSBETUkgMi43IHByZXNlbnQuDQooWEVOKSBVc2luZyBBUElD IGRyaXZlciBkZWZhdWx0DQooWEVOKSBBQ1BJOiBQTS1UaW1lciBJTyBQb3J0OiAweDQwOA0K KFhFTikgQUNQSTogU0xFRVAgSU5GTzogcG0xeF9jbnRbMTo0MDQsMTowXSwgcG0xeF9ldnRb MTo0MDAsMTowXQ0KKFhFTikgQUNQSTogMzIvNjRYIEZBQ1MgYWRkcmVzcyBtaXNtYXRjaCBp biBGQURUIC0gN2UwZTgwODAvMDAwMDAwMDAwMDAwMDAwMCwgdXNpbmcgMzINCihYRU4pIEFD UEk6ICAgICAgICAgICAgIHdha2V1cF92ZWNbN2UwZTgwOGNdLCB2ZWNfc2l6ZVsyMF0NCihY RU4pIEFDUEk6IExvY2FsIEFQSUMgYWRkcmVzcyAweGZlZTAwMDAwDQooWEVOKSBBQ1BJOiBM QVBJQyAoYWNwaV9pZFsweDAwXSBsYXBpY19pZFsweDAwXSBlbmFibGVkKQ0KKFhFTikgUHJv Y2Vzc29yICMwIDc6MTQgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNw aV9pZFsweDAyXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMy IDc6MTQgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA0 XSBsYXBpY19pZFsweDA0XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM0IDc6MTQgQVBJ QyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA2XSBsYXBpY19p ZFsweDA2XSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM2IDc6MTQgQVBJQyB2ZXJzaW9u IDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA4XSBsYXBpY19pZFsweDA4XSBl bmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICM4IDc6MTQgQVBJQyB2ZXJzaW9uIDIxDQooWEVO KSBBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBhXSBsYXBpY19pZFsweDBhXSBlbmFibGVkKQ0K KFhFTikgUHJvY2Vzc29yICMxMCA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTog TEFQSUMgKGFjcGlfaWRbMHgwMV0gbGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFBy b2Nlc3NvciAjMSA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFj cGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj MyA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgw NV0gbGFwaWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNSA3OjE0IEFQ SUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNf aWRbMHgwN10gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNyA3OjE0IEFQSUMgdmVyc2lv biAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0gbGFwaWNfaWRbMHgwOV0g ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjOSA3OjE0IEFQSUMgdmVyc2lvbiAyMQ0KKFhF TikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwYl0gbGFwaWNfaWRbMHgwYl0gZW5hYmxlZCkN CihYRU4pIFByb2Nlc3NvciAjMTEgNzoxNCBBUElDIHZlcnNpb24gMjENCihYRU4pIEFDUEk6 IExBUElDX05NSSAoYWNwaV9pZFsweDAwXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikg QUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDJdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQoo WEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgx XSkNCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA2XSBoaWdoIGVkZ2UgbGlu dFsweDFdKQ0KKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDhdIGhpZ2ggZWRn ZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwYV0gaGln aCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDAx XSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lk WzB4MDNdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFj cGlfaWRbMHgwNV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFDUEk6IExBUElDX05N SSAoYWNwaV9pZFsweDA3XSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikgQUNQSTogTEFQ SUNfTk1JIChhY3BpX2lkWzB4MDldIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJ OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwYl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4p IE92ZXJyaWRpbmcgQVBJQyBkcml2ZXIgd2l0aCBiaWdzbXANCihYRU4pIEFDUEk6IElPQVBJ QyAoaWRbMHgwMF0gYWRkcmVzc1sweGZlYzAwMDAwXSBnc2lfYmFzZVswXSkNCihYRU4pIElP QVBJQ1swXTogYXBpY19pZCAwLCB2ZXJzaW9uIDMyLCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdT SSAwLTIzDQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MDJdIGFkZHJlc3NbMHhmZWMwMTAw MF0gZ3NpX2Jhc2VbMjRdKQ0KKFhFTikgSU9BUElDWzFdOiBhcGljX2lkIDIsIHZlcnNpb24g MzIsIGFkZHJlc3MgMHhmZWMwMTAwMCwgR1NJIDI0LTQ3DQooWEVOKSBBQ1BJOiBJTlRfU1JD X09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBkZmwgZGZsKQ0KKFhFTikgQUNQ STogSU5UX1NSQ19PVlIgKGJ1cyAwIGJ1c19pcnEgOSBnbG9iYWxfaXJxIDkgaGlnaCBsZXZl bCkNCihYRU4pIEFDUEk6IElSUTAgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElS UTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTkgdXNlZCBieSBvdmVycmlk ZS4NCihYRU4pIEVuYWJsaW5nIEFQSUMgbW9kZTogIFBoeXMuICBVc2luZyAyIEkvTyBBUElD cw0KKFhFTikgQUNQSTogSFBFVCBpZDogMHg4MDg2YTcwMSBiYXNlOiAweGZlZDAwMDAwDQoo WEVOKSBbVlQtRF1kbWFyLmM6Nzg4OiBIb3N0IGFkZHJlc3Mgd2lkdGggNDYNCihYRU4pIFtW VC1EXWRtYXIuYzo4MDI6IGZvdW5kIEFDUElfRE1BUl9EUkhEOg0KKFhFTikgW1ZULURdZG1h ci5jOjQ3MjogICBkbWFydS0+YWRkcmVzcyA9IGZiZmZjMDAwDQooWEVOKSBbVlQtRF1pb21t dS5jOjExMzc6IGRyaGQtPmFkZHJlc3MgPSBmYmZmYzAwMCBpb21tdS0+cmVnID0gZmZmZjgy YzAwMDIwMTAwMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxMTM5OiBjYXAgPSBkMjA3OGMxMDZm MDQ2NiBlY2FwID0gZjAyMGRlDQooWEVOKSBbVlQtRF1kbWFyLmM6Mzk3OiAgSU9BUElDOiAw MDAwOjAwOjFmLjcNCihYRU4pIFtWVC1EXWRtYXIuYzozOTc6ICBJT0FQSUM6IDAwMDA6MDA6 MDUuNA0KKFhFTikgW1ZULURdZG1hci5jOjM2MTogIE1TSSBIUEVUOiAwMDAwOmYwOjBmLjAN CihYRU4pIFtWVC1EXWRtYXIuYzo0ODY6ICAgZmxhZ3M6IElOQ0xVREVfQUxMDQooWEVOKSBb VlQtRF1kbWFyLmM6ODA3OiBmb3VuZCBBQ1BJX0RNQVJfUk1SUjoNCihYRU4pIFtWVC1EXWRt YXIuYzozODM6ICBlbmRwb2ludDogMDAwMDowMDoxZC4wDQooWEVOKSBbVlQtRF1kbWFyLmM6 MzgzOiAgZW5kcG9pbnQ6IDAwMDA6MDA6MWEuMA0KKFhFTikgW1ZULURdZG1hci5jOjY3Njog ICBSTVJSIHJlZ2lvbjogYmFzZV9hZGRyIDdkZGI1MDAwIGVuZF9hZGRyZXNzIDdkZGMxZmZm DQooWEVOKSBbVlQtRF1kbWFyLmM6ODEyOiBmb3VuZCBBQ1BJX0RNQVJfQVRTUjoNCihYRU4p IFtWVC1EXWRtYXIuYzo3MDU6ICAgYXRzcnUtPmFsbF9wb3J0czogMA0KKFhFTikgW1ZULURd ZG1hci5jOjM1MzogIGJyaWRnZTogMDAwMDowMDowMS4wIHN0YXJ0PTAgc2VjPTEgc3ViPTIN CihYRU4pIFtWVC1EXWRtYXIuYzozNTM6ICBicmlkZ2U6IDAwMDA6MDA6MDIuMCBzdGFydD0w IHNlYz0zIHN1Yj00DQooWEVOKSBbVlQtRF1kbWFyLmM6MzUzOiAgYnJpZGdlOiAwMDAwOjAw OjAyLjIgc3RhcnQ9MCBzZWM9NSBzdWI9Yg0KKFhFTikgW1ZULURdZG1hci5jOjM1MzogIGJy aWRnZTogMDAwMDowMDowMy4wIHN0YXJ0PTAgc2VjPWMgc3ViPWMNCihYRU4pIFtWVC1EXWRt YXIuYzozNTM6ICBicmlkZ2U6IDAwMDA6MDA6MDMuMiBzdGFydD0wIHNlYz1kIHN1Yj1kDQoo WEVOKSBbVlQtRF1kbWFyLmM6ODE3OiBmb3VuZCBBQ1BJX0RNQVJfUkhTQToNCihYRU4pIFtW VC1EXWRtYXIuYzo3NTc6ICAgcmhzYXUtPmFkZHJlc3M6IGZiZmZjMDAwIHJoc2F1LT5wcm94 aW1pdHlfZG9tYWluOiAwDQooWEVOKSBYZW4gRVJTVCBzdXBwb3J0IGlzIGluaXRpYWxpemVk Lg0KKFhFTikgSEVTVDogVGFibGUgcGFyc2luZyBoYXMgYmVlbiBpbml0aWFsaXplZA0KKFhF TikgVXNpbmcgQUNQSSAoTUFEVCkgZm9yIFNNUCBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9u DQooWEVOKSBTTVA6IEFsbG93aW5nIDEyIENQVXMgKDAgaG90cGx1ZyBDUFVzKQ0KKFhFTikg SVJRIGxpbWl0czogNDggR1NJLCAyMjcyIE1TSS9NU0ktWA0KKFhFTikgU3dpdGNoZWQgdG8g QVBJQyBkcml2ZXIgeDJhcGljX2NsdXN0ZXIuDQooWEVOKSBVc2luZyBzY2hlZHVsZXI6IFNN UCBDcmVkaXQgU2NoZWR1bGVyIChjcmVkaXQpDQooWEVOKSBEZXRlY3RlZCAyMTAwLjA4MiBN SHogcHJvY2Vzc29yLg0KKFhFTikgSW5pdGluZyBtZW1vcnkgc2hhcmluZy4NCihYRU4pIHhz dGF0ZV9pbml0OiB1c2luZyBjbnR4dF9zaXplOiAweDM0MCBhbmQgc3RhdGVzOiAweDcNCihY RU4pIG1jZV9pbnRlbC5jOjczNTogTUNBIENhcGFiaWxpdHk6IEJDQVNUIDEgU0VSIDEgQ01D SSAxIGZpcnN0YmFuayAwIGV4dGVuZGVkIE1DRSBNU1IgMA0KKFhFTikgSW50ZWwgbWFjaGlu ZSBjaGVjayByZXBvcnRpbmcgZW5hYmxlZA0KKFhFTikgYWx0IHRhYmxlIGZmZmY4MmQwODAy ZGQ5OTAgLT4gZmZmZjgyZDA4MDJkZWJkOA0KKFhFTikgUENJOiBNQ0ZHIGNvbmZpZ3VyYXRp b24gMDogYmFzZSA4MDAwMDAwMCBzZWdtZW50IDAwMDAgYnVzZXMgMDAgLSBmZg0KKFhFTikg UENJOiBNQ0ZHIGFyZWEgYXQgODAwMDAwMDAgcmVzZXJ2ZWQgaW4gRTgyMA0KKFhFTikgUENJ OiBVc2luZyBNQ0ZHIGZvciBzZWdtZW50IDAwMDAgYnVzIDAwLWZmDQooWEVOKSBJbnRlbCBW VC1kIGlvbW11IDAgc3VwcG9ydGVkIHBhZ2Ugc2l6ZXM6IDRrQiwgMk1CLCAxR0IuDQooWEVO KSBJbnRlbCBWVC1kIFNub29wIENvbnRyb2wgZW5hYmxlZC4NCihYRU4pIEludGVsIFZULWQg RG9tMCBETUEgUGFzc3Rocm91Z2ggbm90IGVuYWJsZWQuDQooWEVOKSBJbnRlbCBWVC1kIFF1 ZXVlZCBJbnZhbGlkYXRpb24gZW5hYmxlZC4NCihYRU4pIEludGVsIFZULWQgSW50ZXJydXB0 IFJlbWFwcGluZyBlbmFibGVkLg0KKFhFTikgSW50ZWwgVlQtZCBTaGFyZWQgRVBUIHRhYmxl cyBlbmFibGVkLg0KKFhFTikgSS9PIHZpcnR1YWxpc2F0aW9uIGVuYWJsZWQNCihYRU4pICAt IERvbTAgbW9kZTogUmVsYXhlZA0KKFhFTikgSW50ZXJydXB0IHJlbWFwcGluZyBlbmFibGVk DQooWEVOKSBFbmFibGVkIGRpcmVjdGVkIEVPSSB3aXRoIGlvYXBpY19hY2tfb2xkIG9uIQ0K KFhFTikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzDQooWEVOKSAgLT4gVXNpbmcgb2xkIEFDSyBt ZXRob2QNCihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMy PS0xIHBpbjI9LTENCihYRU4pIFRTQyBkZWFkbGluZSB0aW1lciBlbmFibGVkDQooWEVOKSBQ bGF0Zm9ybSB0aW1lciBpcyAxNC4zMThNSHogSFBFVA0KKFhFTikgQWxsb2NhdGVkIGNvbnNv bGUgcmluZyBvZiAxMjggS2lCLg0KKFhFTikgbXdhaXQtaWRsZTogTVdBSVQgc3Vic3RhdGVz OiAweDExMjANCihYRU4pIG13YWl0LWlkbGU6IHYwLjQgbW9kZWwgMHgzZQ0KKFhFTikgbXdh aXQtaWRsZTogbGFwaWNfdGltZXJfcmVsaWFibGVfc3RhdGVzIDB4ZmZmZmZmZmYNCihYRU4p IFZNWDogU3VwcG9ydGVkIGFkdmFuY2VkIGZlYXR1cmVzOg0KKFhFTikgIC0gQVBJQyBNTUlP IGFjY2VzcyB2aXJ0dWFsaXNhdGlvbg0KKFhFTikgIC0gQVBJQyBUUFIgc2hhZG93DQooWEVO KSAgLSBFeHRlbmRlZCBQYWdlIFRhYmxlcyAoRVBUKQ0KKFhFTikgIC0gVmlydHVhbC1Qcm9j ZXNzb3IgSWRlbnRpZmllcnMgKFZQSUQpDQooWEVOKSAgLSBWaXJ0dWFsIE5NSQ0KKFhFTikg IC0gTVNSIGRpcmVjdC1hY2Nlc3MgYml0bWFwDQooWEVOKSAgLSBVbnJlc3RyaWN0ZWQgR3Vl c3QNCihYRU4pICAtIEFQSUMgUmVnaXN0ZXIgVmlydHVhbGl6YXRpb24NCihYRU4pICAtIFZp cnR1YWwgSW50ZXJydXB0IERlbGl2ZXJ5DQooWEVOKSAgLSBQb3N0ZWQgSW50ZXJydXB0IFBy b2Nlc3NpbmcNCihYRU4pIEhWTTogQVNJRHMgZW5hYmxlZC4NCihYRU4pIEhWTTogVk1YIGVu YWJsZWQNCihYRU4pIEhWTTogSGFyZHdhcmUgQXNzaXN0ZWQgUGFnaW5nIChIQVApIGRldGVj dGVkDQooWEVOKSBIVk06IEhBUCBwYWdlIHNpemVzOiA0a0IsIDJNQiwgMUdCDQooWEVOKSBC cm91Z2h0IHVwIDEyIENQVXMNCihYRU4pIEFDUEkgc2xlZXAgbW9kZXM6IFMzDQooWEVOKSBt Y2hlY2tfcG9sbDogTWFjaGluZSBjaGVjayBwb2xsaW5nIHRpbWVyIHN0YXJ0ZWQuDQooWEVO KSBEb20wIGhhcyBtYXhpbXVtIDgxNiBQSVJRcw0KKFhFTikgKioqIExPQURJTkcgRE9NQUlO IDAgKioqDQooWEVOKSBlbGZfcGFyc2VfYmluYXJ5OiBwaGRyOiBwYWRkcj0weGZmZmZmZmZm ODAyMDAwMDAgbWVtc3o9MHg2YjM2Y2MNCihYRU4pIGVsZl9wYXJzZV9iaW5hcnk6IHBoZHI6 IHBhZGRyPTB4ZmZmZmZmZmY4MGFiMzZkMCBtZW1zej0weDFlMjc5OA0KKFhFTikgZWxmX3Bh cnNlX2JpbmFyeTogbWVtb3J5OiAweGZmZmZmZmZmODAyMDAwMDAgLT4gMHhmZmZmZmZmZjgw Yzk1ZTY4DQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX09TID0gIkZyZWVCU0Qi DQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEdVRVNUX1ZFUlNJT04gPSAiMHgxMGM5MjMi DQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFhFTl9WRVJTSU9OID0gInhlbi0zLjAiDQoo WEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IFZJUlRfQkFTRSA9IDB4ZmZmZmZmZmY4MDAwMDAw MA0KKFhFTikgZWxmX3hlbl9wYXJzZV9ub3RlOiBQQUREUl9PRkZTRVQgPSAweGZmZmZmZmZm ODAwMDAwMDANCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogRU5UUlkgPSAweGZmZmZmZmZm ODA3OGEwMDANCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFlQRVJDQUxMX1BBR0UgPSAw eGZmZmZmZmZmODA3ODkwMDANCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogSFZfU1RBUlRf TE9XID0gMHhmZmZmODAwMDAwMDAwMDAwDQooWEVOKSBlbGZfeGVuX3BhcnNlX25vdGU6IEZF QVRVUkVTID0gIndyaXRhYmxlX2Rlc2NyaXB0b3JfdGFibGVzfGF1dG9fdHJhbnNsYXRlZF9w aHlzbWFwfHN1cGVydmlzb3JfbW9kZV9rZXJuZWx8aHZtX2NhbGxiYWNrX3ZlY3RvciINCihY RU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTogUEFFX01PREUgPSAieWVzIg0KKFhFTikgZWxmX3hl bl9wYXJzZV9ub3RlOiB1bmtub3duIHhlbiBlbGYgbm90ZSAoMHhkKQ0KKFhFTikgZWxmX3hl bl9wYXJzZV9ub3RlOiBMT0FERVIgPSAiZ2VuZXJpYyINCihYRU4pIGVsZl94ZW5fcGFyc2Vf bm90ZTogU1VTUEVORF9DQU5DRUwgPSAweDANCihYRU4pIGVsZl94ZW5fcGFyc2Vfbm90ZTog QlNEX1NZTVRBQiA9ICJ5ZXMiDQooWEVOKSBlbGZfeGVuX3BhcnNlOiB1c2luZyBub3RlcyBm cm9tIFNIVF9OT1RFIHNlY3Rpb24NCihYRU4pIGVsZl94ZW5fYWRkcl9jYWxjX2NoZWNrOiBh ZGRyZXNzZXM6DQooWEVOKSAgICAgdmlydF9iYXNlICAgICAgICA9IDB4ZmZmZmZmZmY4MDAw MDAwMA0KKFhFTikgICAgIGVsZl9wYWRkcl9vZmZzZXQgPSAweGZmZmZmZmZmODAwMDAwMDAN CihYRU4pICAgICB2aXJ0X29mZnNldCAgICAgID0gMHgwDQooWEVOKSAgICAgdmlydF9rc3Rh cnQgICAgICA9IDB4ZmZmZmZmZmY4MDIwMDAwMA0KKFhFTikgICAgIHZpcnRfa2VuZCAgICAg ICAgPSAweGZmZmZmZmZmODBlMWNlYTANCihYRU4pICAgICB2aXJ0X2VudHJ5ICAgICAgID0g MHhmZmZmZmZmZjgwNzhhMDAwDQooWEVOKSAgICAgcDJtX2Jhc2UgICAgICAgICA9IDB4ZmZm ZmZmZmZmZmZmZmZmZg0KKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxzYiwgY29tcGF0 MzINCihYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIgMHhmZmZm ZmZmZjgwMjAwMDAwIC0+IDB4ZmZmZmZmZmY4MGM5NWU2OA0KKFhFTikgIERvbTAgc3ltYm9s IG1hcCAweGZmZmZmZmZmODBjOTVlNjggLT4gMHhmZmZmZmZmZjgwZTFjZWEwDQooWEVOKSBQ SFlTSUNBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVOKSAgRG9tMCBhbGxvYy46ICAgMDAw MDAwMDQ3MDAwMDAwMC0+MDAwMDAwMDQ3MjAwMDAwMCAoMjA4NzcyMSBwYWdlcyB0byBiZSBh bGxvY2F0ZWQpDQooWEVOKSAgSW5pdC4gcmFtZGlzazogMDAwMDAwMDQ3ZmIyOTAwMC0+MDAw MDAwMDQ4MDAwMDAwMA0KKFhFTikgVklSVFVBTCBNRU1PUlkgQVJSQU5HRU1FTlQ6DQooWEVO KSAgTG9hZGVkIGtlcm5lbDogZmZmZmZmZmY4MDIwMDAwMC0+ZmZmZmZmZmY4MGUxY2VhMA0K KFhFTikgIEluaXQuIHJhbWRpc2s6IGZmZmZmZmZmODBlMWQwMDAtPmZmZmZmZmZmODEyZjQw MDANCihYRU4pICBQaHlzLU1hY2ggbWFwOiBmZmZmZmZmZjgxMmY0MDAwLT5mZmZmZmZmZjgy MmY0MDAwDQooWEVOKSAgU3RhcnQgaW5mbzogICAgZmZmZmZmZmY4MjJmNDAwMC0+ZmZmZmZm ZmY4MjJmNTRiNA0KKFhFTikgIFBhZ2UgdGFibGVzOiAgIGZmZmZmZmZmODIyZjYwMDAtPmZm ZmZmZmZmODIzMGIwMDANCihYRU4pICBCb290IHN0YWNrOiAgICBmZmZmZmZmZjgyMzBiMDAw LT5mZmZmZmZmZjgyMzBjMDAwDQooWEVOKSAgVE9UQUw6ICAgICAgICAgZmZmZmZmZmY4MDAw MDAwMC0+ZmZmZmZmZmY4MjQwMDAwMA0KKFhFTikgIEVOVFJZIEFERFJFU1M6IGZmZmZmZmZm ODA3OGEwMDANCihYRU4pIERvbTAgaGFzIG1heGltdW0gNCBWQ1BVcw0KKFhFTikgZWxmX2xv YWRfYmluYXJ5OiBwaGRyIDIgYXQgMHhmZmZmZmZmZjgwMjAwMDAwIC0+IDB4ZmZmZmZmZmY4 MDhiMzZjYw0KKFhFTikgZWxmX2xvYWRfYmluYXJ5OiBwaGRyIDMgYXQgMHhmZmZmZmZmZjgw YWIzNmQwIC0+IDB4ZmZmZmZmZmY4MGIzMjdmOA0KKFhFTikgZWxmX2xvYWRfYnNkc3ltczog c2hkciA0IGF0IDB4ZmZmZjgzMDQ3ZjI4YTMwOCAtPiAweGZmZmZmZmZmODBjOTY3YjANCihY RU4pIGVsZl9sb2FkX2JzZHN5bXM6IHNoZHIgMzMgYXQgMHhmZmZmODMwNDdmOWNjMTBhIC0+ IDB4ZmZmZmZmZmY4MGNjMTE4MA0KKFhFTikgZWxmX2xvYWRfYnNkc3ltczogc2hkciAzNCBh dCAweGZmZmY4MzA0N2Y5Y2NiYjggLT4gMHhmZmZmZmZmZjgwY2MxMzMwDQooWEVOKSBlbGZf bG9hZF9ic2RzeW1zOiBzaGRyIDM1IGF0IDB4ZmZmZjgzMDQ3ZmE3OGJmMCAtPiAweGZmZmZm ZmZmODBkNmQzNjgNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQyMTogZDA6SG9zdGJyaWRnZTog c2tpcCAwMDAwOjAwOjAwLjAgbWFwDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0MzU6IGQwOlBD SWU6IG1hcCAwMDAwOjAwOjA0LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzNTogZDA6UENJ ZTogbWFwIDAwMDA6MDA6MDQuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDM1OiBkMDpQQ0ll OiBtYXAgMDAwMDowMDowNC4yDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6 IG1hcCAwMDAwOjAwOjA0LjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzNTogZDA6UENJZTog bWFwIDAwMDA6MDA6MDQuNA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBt YXAgMDAwMDowMDowNC41DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6IG1h cCAwMDAwOjAwOjA0LjYNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzNTogZDA6UENJZTogbWFw IDAwMDA6MDA6MDQuNw0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAg MDAwMDowMDowNS4wDQooWEVOKSBNYXNrZWQgVlQtZCBlcnJvciBzaWduYWxpbmcgb24gMDAw MDowMDowNS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAw OjAwOjA1LjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6 MDA6MDUuNA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBkMDpQQ0k6IG1hcCAwMDAwOjAw OjE2LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6UENJOiBtYXAgMDAwMDowMDox Ni4xDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6IGQwOlBDSTogbWFwIDAwMDA6MDA6MWEu MA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjFkLjAN CihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6UENJOiBtYXAgMDAwMDowMDoxZi4wDQoo WEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6IGQwOlBDSTogbWFwIDAwMDA6MDA6MWYuMg0KKFhF TikgW1ZULURdaW9tbXUuYzoxNDQ3OiBkMDpQQ0k6IG1hcCAwMDAwOjAwOjFmLjMNCihYRU4p IFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6UENJOiBtYXAgMDAwMDowMDoxZi42DQooWEVOKSBb VlQtRF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOjAxOjAwLjANCihYRU4pIFtW VC1EXWlvbW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6MDE6MDAuMQ0KKFhFTikgW1ZU LURdaW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDowMzowMC4wDQooWEVOKSBbVlQt RF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOjAzOjAwLjENCihYRU4pIFtWVC1E XWlvbW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6MDM6MDAuMg0KKFhFTikgW1ZULURd aW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDowMzowMC4zDQooWEVOKSBbVlQtRF1p b21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOjA3OjAwLjANCihYRU4pIFtWVC1EXWlv bW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6MDc6MDAuMQ0KKFhFTikgW1ZULURdaW9t bXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDowNzowMC4yDQooWEVOKSBbVlQtRF1pb21t dS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOjA3OjAwLjMNCihYRU4pIFtWVC1EXWlvbW11 LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6MDk6MDAuMA0KKFhFTikgW1ZULURdaW9tbXUu YzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDowOTowMC4xDQooWEVOKSBbVlQtRF1pb21tdS5j OjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOjA5OjAwLjINCihYRU4pIFtWVC1EXWlvbW11LmM6 MTQzNTogZDA6UENJZTogbWFwIDAwMDA6MDk6MDAuMw0KKFhFTikgW1ZULURdaW9tbXUuYzox NDM1OiBkMDpQQ0llOiBtYXAgMDAwMDowZjowMC4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0 MzU6IGQwOlBDSWU6IG1hcCAwMDAwOjBmOjAwLjENCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0 NzogZDA6UENJOiBtYXAgMDAwMDoxMTowNC4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6 IGQwOlBDSTogbWFwIDAwMDA6ZmY6MDguMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBk MDpQQ0k6IG1hcCAwMDAwOmZmOjA5LjANCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6 UENJOiBtYXAgMDAwMDpmZjowYS4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6IGQwOlBD STogbWFwIDAwMDA6ZmY6MGEuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBkMDpQQ0k6 IG1hcCAwMDAwOmZmOjBhLjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6UENJOiBt YXAgMDAwMDpmZjowYS4zDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6IGQwOlBDSTogbWFw IDAwMDA6ZmY6MGIuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBkMDpQQ0k6IG1hcCAw MDAwOmZmOjBiLjMNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6UENJOiBtYXAgMDAw MDpmZjowYy4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6IGQwOlBDSTogbWFwIDAwMDA6 ZmY6MGMuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBkMDpQQ0k6IG1hcCAwMDAwOmZm OjBjLjINCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6UENJOiBtYXAgMDAwMDpmZjow ZC4wDQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6IGQwOlBDSTogbWFwIDAwMDA6ZmY6MGQu MQ0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBkMDpQQ0k6IG1hcCAwMDAwOmZmOjBkLjIN CihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6UENJOiBtYXAgMDAwMDpmZjowZS4wDQoo WEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6IGQwOlBDSTogbWFwIDAwMDA6ZmY6MGUuMQ0KKFhF TikgW1ZULURdaW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDpmZjowZi4wDQooWEVO KSBbVlQtRF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOmZmOjBmLjENCihYRU4p IFtWVC1EXWlvbW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6ZmY6MGYuMg0KKFhFTikg W1ZULURdaW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDpmZjowZi4zDQooWEVOKSBb VlQtRF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOmZmOjBmLjQNCihYRU4pIFtW VC1EXWlvbW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6ZmY6MGYuNQ0KKFhFTikgW1ZU LURdaW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDpmZjoxMC4wDQooWEVOKSBbVlQt RF1pb21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOmZmOjEwLjENCihYRU4pIFtWVC1E XWlvbW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6ZmY6MTAuMg0KKFhFTikgW1ZULURd aW9tbXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDpmZjoxMC4zDQooWEVOKSBbVlQtRF1p b21tdS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOmZmOjEwLjQNCihYRU4pIFtWVC1EXWlv bW11LmM6MTQzNTogZDA6UENJZTogbWFwIDAwMDA6ZmY6MTAuNQ0KKFhFTikgW1ZULURdaW9t bXUuYzoxNDM1OiBkMDpQQ0llOiBtYXAgMDAwMDpmZjoxMC42DQooWEVOKSBbVlQtRF1pb21t dS5jOjE0MzU6IGQwOlBDSWU6IG1hcCAwMDAwOmZmOjEwLjcNCihYRU4pIFtWVC1EXWlvbW11 LmM6MTQ0NzogZDA6UENJOiBtYXAgMDAwMDpmZjoxMy4wDQooWEVOKSBbVlQtRF1pb21tdS5j OjE0NDc6IGQwOlBDSTogbWFwIDAwMDA6ZmY6MTMuMQ0KKFhFTikgW1ZULURdaW9tbXUuYzox NDQ3OiBkMDpQQ0k6IG1hcCAwMDAwOmZmOjEzLjQNCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0 NzogZDA6UENJOiBtYXAgMDAwMDpmZjoxMy41DQooWEVOKSBbVlQtRF1pb21tdS5jOjE0NDc6 IGQwOlBDSTogbWFwIDAwMDA6ZmY6MTYuMA0KKFhFTikgW1ZULURdaW9tbXUuYzoxNDQ3OiBk MDpQQ0k6IG1hcCAwMDAwOmZmOjE2LjENCihYRU4pIFtWVC1EXWlvbW11LmM6MTQ0NzogZDA6 UENJOiBtYXAgMDAwMDpmZjoxNi4yDQooWEVOKSBbVlQtRF1pb21tdS5jOjczMDogaW9tbXVf ZW5hYmxlX3RyYW5zbGF0aW9uOiBpb21tdS0+cmVnID0gZmZmZjgyYzAwMDIwMTAwMA0KKFhF TikgU2NydWJiaW5nIEZyZWUgUkFNIG9uIDEgbm9kZXMgdXNpbmcgNiBDUFVzDQooWEVOKSAu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi5kb25lLg0KKFhFTikgSW5pdGlhbCBsb3cgbWVtb3J5 IHZpcnEgdGhyZXNob2xkIHNldCBhdCAweDQwMDAgcGFnZXMuDQooWEVOKSBTdGQuIExvZ2xl dmVsOiBBbGwNCihYRU4pIEd1ZXN0IExvZ2xldmVsOiBFcnJvcnMgYW5kIHdhcm5pbmdzDQoo WEVOKSBYZW4gaXMgcmVsaW5xdWlzaGluZyBWR0EgY29uc29sZS4NCihYRU4pICoqKiBTZXJp YWwgaW5wdXQgLT4gRE9NMCAodHlwZSAnQ1RSTC1hJyB0aHJlZSB0aW1lcyB0byBzd2l0Y2gg aW5wdXQgdG8gWGVuKQ0KKFhFTikgRnJlZWQgMzA4a0IgaW5pdCBtZW1vcnkuDQooWEVOKSA8 dm1fbGF1bmNoX2ZhaWw+IGVycm9yIGNvZGUgNw0KKFhFTikgZG9tYWluX2NyYXNoX3N5bmMg Y2FsbGVkIGZyb20gdm1jcy5jOjEzMTkNCihYRU4pIERvbWFpbiAwICh2Y3B1IzApIGNyYXNo ZWQgb24gY3B1IzA6DQooWEVOKSAtLS0tWyBYZW4tNC42LXVuc3RhYmxlICB4ODZfNjQgIGRl YnVnPXkgIE5vdCB0YWludGVkIF0tLS0tDQooWEVOKSBDUFU6ICAgIDANCihYRU4pIFJJUDog ICAgMDAwMDpbPGZmZmZmZmZmODA3OGEwMDA+XQ0KKFhFTikgUkZMQUdTOiAwMDAwMDAwMDAw MDAwMjAwICAgQ09OVEVYVDogaHZtIGd1ZXN0DQooWEVOKSByYXg6IDAwMDAwMDAwMDAwMDAw MDAgICByYng6IGZmZmY4MmQwODAyZTgwMDAgICByY3g6IGZmZmY4MmQwODAyZWZmODANCihY RU4pIHJkeDogZmZmZjgyZDA4MDFlMDhhOCAgIHJzaTogMDAwMDAwMDAwMDAwMDAwMCAgIHJk aTogZmZmZjgyZDA4MDFlY2IwYw0KKFhFTikgcmJwOiBmZmZmODJkMDgwMTA1ZmE2ICAgcnNw OiBmZmZmZmZmZjgyMzBjMDAwICAgcjg6ICBmZmZmODMwNDc0MWMwMDAwDQooWEVOKSByOTog IGZmZmY4MmQwODAxMDYwMTMgICByMTA6IGZmZmY4MmQwODAyZWZmNzAgICByMTE6IDAwMDAw MDAwMDAwMDAwMDANCihYRU4pIHIxMjogZmZmZjgyZDA4MDJlZmY1MCAgIHIxMzogZmZmZjgz MDQ3M2ZjOTAwMCAgIHIxNDogZmZmZjgzMDQ3NDFjMDAwMA0KKFhFTikgcjE1OiBmZmZmODJk MDgwMThlNTQ3ICAgY3IwOiAwMDAwMDAwMDgwMDAwMDExICAgY3I0OiAwMDAwMDAwMDAwMDAw MDIwDQooWEVOKSBjcjM6IDAwMDAwMDAwMDIyZjYwMDAgICBjcjI6IDAwMDAwMDAwMDAwMDAw MDANCihYRU4pIGRzOiAwMDAwICAgZXM6IDAwMDAgICBmczogMDAwMCAgIGdzOiAwMDAwICAg c3M6IDAwMDAgICBjczogMDAwMA0KKFhFTikgR3Vlc3Qgc3RhY2sgdHJhY2UgZnJvbSByc3A9 ZmZmZmZmZmY4MjMwYzAwMDoNCihYRU4pICAgRmF1bHQgd2hpbGUgYWNjZXNzaW5nIGd1ZXN0 IG1lbW9yeS4NCihYRU4pIERvbWFpbiAwIGNyYXNoZWQ6IHJlYm9vdGluZyBtYWNoaW5lIGlu IDUgc2Vjb25kcy4NCg0K4oCNDQoNCg0KDQoNClJlZ2FyZHMsDQpHYXZpbiBNdeKAjQ== From owner-freebsd-xen@FreeBSD.ORG Thu Apr 2 16:41:06 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D04C5FA for ; Thu, 2 Apr 2015 16:41:06 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49C1DF2D for ; Thu, 2 Apr 2015 16:41:04 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.11,512,1422921600"; d="scan'208";a="249240069" Message-ID: <551D70B3.5020601@citrix.com> Date: Thu, 2 Apr 2015 18:39:15 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Gavin Mu , freebsd-xen , xen-devel Subject: Re: failed to boot FreeBSD 11-CURRENT as Xen Dom0 References: In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:41:06 -0000 Hello, El 02/04/15 a les 18.23, Gavin Mu ha escrit: > Today I tried Xen Dom0 on one SuperMicro X9SRW-F machine, but it failed to bootup. Is there anybody can help? thanks. > > (XEN) Xen version 4.6-unstable (root@) (gcc47 (FreeBSD Ports Collection) 4.7.4) debug=y Fri Apr 3 00:04:50 CST 2015 > (XEN) Latest ChangeSet: Tue Mar 17 15:11:33 2015 +0100 git:3a28f76 > (XEN) Bootloader: FreeBSD Loader > (XEN) Command line: dom0_mem=8192M dom0_max_vcpus=4 dom0pvh=1 com2=115200,8n1,0x2f8 guest_loglvl console=com2,vga iommu=debug > (XEN) Video information: > (XEN) VGA is text mode 80x25, font 8x16 > (XEN) VBE/DDC methods: none; EDID transfer time: 0 seconds > (XEN) EDID info not retrieved because no DDC retrieval method detected > (XEN) Disc information: | > (XEN) Found 1 MBR signatures] | > (XEN) Found 1 EDD information structures | > (XEN) Xen-e820 RAM map:er prompt | > (XEN) 0000000000000000 - 000000000009ac00 (usable) > (XEN) 000000000009ac00 - 00000000000a0000 (reserved) > (XEN) 00000000000e0000 - 0000000000100000 (reserved) > (XEN) 0000000000100000 - 000000007dda0000 (usable) > (XEN) 000000007dda0000 - 000000007dddf000 (reserved) > (XEN) 000000007dddf000 - 000000007dee6000 (ACPI data) > (XEN) 000000007dee6000 - 000000007e0f1000 (ACPI NVS) > (XEN) 000000007e0f1000 - 000000007f36b000 (reserved) > (XEN) 000000007f36b000 - 000000007f800000 (ACPI NVS) > (XEN) 0000000080000000 - 0000000090000000 (reserved) > (XEN) 00000000fed1c000 - 00000000fed40000 (reserved) > (XEN) 00000000ff000000 - 0000000100000000 (reserved) > (XEN) 0000000100000000 - 0000000480000000 (usable)R > (XEN) ACPI: RSDP 000F04A0, 0024 (r2 SUPERM)eBSD. > (XEN) ACPI: XSDT 7DE13088, 008C (r1 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: FACP 7DE1D8F0, 00F4 (r4 SUPERM SMCI--MB 1 AMI 10013) > (XEN) ACPI: DSDT 7DE131A0, A74A (r2 SUPERM SMCI--MB 0 INTL 20091112) > (XEN) ACPI: FACS 7E0E8080, 0040, 'help' for more detailed help. > (XEN) ACPI: APIC 7DE1D9E8, 0100 (r3 1 AMI 10013) > (XEN) ACPI: FPDT 7DE1DAE8, 0044 (r1 1 AMI 10013) > (XEN) ACPI: HPET 7DE1DB30, 0038 (r1 SUPERM SMCI--MB 1 AMI. 5) > (XEN) ACPI: PRAD 7DE1DB68, 00BE (r2 PRADID PRADTID 1 MSFT 4000000) > (XEN) ACPI: SPMI 7DE1DC28, 0040 (r5 A M I OEMSPMI 0 AMI. 0) > (XEN) ACPI: SSDT 7DE1DC68, C7AE8 (r2 INTEL CpuPm 4000 INTL 20091112) > (XEN) ACPI: EINJ 7DEE5750, 0130 (r1 AMI AMI EINJ 0 0) > (XEN) ACPI: ERST 7DEE5880, 0230 (r1 AMIER AMI ERST 0 0) > (XEN) ACPI: HEST 7DEE5AB0, 00A8 (r1 AMI AMI HEST 0 0) > (XEN) ACPI: BERT 7DEE5B58, 0030 (r1 AMI AMI BERT 0 0) > (XEN) ACPI: DMAR 7DEE5B88, 00C4 (r1 A M I OEMDMAR 1 INTL 1) > (XEN) ACPI: MCFG 7DEE5C50, 003C (r1 SUPERM SMCI--MB 1 MSFT 97) > (XEN) System RAM: 16349MB (16741608kB) > (XEN) No NUMA configuration found > (XEN) Faking a node at 0000000000000000-0000000480000000 > (XEN) Domain heap initialised > (XEN) found SMP MP-table at 000fd950 > (XEN) DMI 2.7 present. > (XEN) Using APIC driver default > (XEN) ACPI: PM-Timer IO Port: 0x408 > (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] > (XEN) ACPI: 32/64X FACS address mismatch in FADT - 7e0e8080/0000000000000000, using 32 > (XEN) ACPI: wakeup_vec[7e0e808c], vec_size[20] > (XEN) ACPI: Local APIC address 0xfee00000 > (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > (XEN) Processor #0 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) > (XEN) Processor #2 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] enabled) > (XEN) Processor #4 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] enabled) > (XEN) Processor #6 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] enabled) > (XEN) Processor #8 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] enabled) > (XEN) Processor #10 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) > (XEN) Processor #1 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled) > (XEN) Processor #3 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] enabled) > (XEN) Processor #5 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] enabled) > (XEN) Processor #7 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] enabled) > (XEN) Processor #9 7:14 APIC version 21 > (XEN) ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] enabled) > (XEN) Processor #11 7:14 APIC version 21 > (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1]) > (XEN) ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1]) > (XEN) Overriding APIC driver with bigsmp > (XEN) ACPI: IOAPIC (id[0x00] address[0xfec00000] gsi_base[0]) > (XEN) IOAPIC[0]: apic_id 0, version 32, address 0xfec00000, GSI 0-23 > (XEN) ACPI: IOAPIC (id[0x02] address[0xfec01000] gsi_base[24]) > (XEN) IOAPIC[1]: apic_id 2, version 32, address 0xfec01000, GSI 24-47 > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > (XEN) ACPI: IRQ0 used by override. > (XEN) ACPI: IRQ2 used by override. > (XEN) ACPI: IRQ9 used by override. > (XEN) Enabling APIC mode: Phys. Using 2 I/O APICs > (XEN) ACPI: HPET id: 0x8086a701 base: 0xfed00000 > (XEN) [VT-D]dmar.c:788: Host address width 46 > (XEN) [VT-D]dmar.c:802: found ACPI_DMAR_DRHD: > (XEN) [VT-D]dmar.c:472: dmaru->address = fbffc000 > (XEN) [VT-D]iommu.c:1137: drhd->address = fbffc000 iommu->reg = ffff82c000201000 > (XEN) [VT-D]iommu.c:1139: cap = d2078c106f0466 ecap = f020de > (XEN) [VT-D]dmar.c:397: IOAPIC: 0000:00:1f.7 > (XEN) [VT-D]dmar.c:397: IOAPIC: 0000:00:05.4 > (XEN) [VT-D]dmar.c:361: MSI HPET: 0000:f0:0f.0 > (XEN) [VT-D]dmar.c:486: flags: INCLUDE_ALL > (XEN) [VT-D]dmar.c:807: found ACPI_DMAR_RMRR: > (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:1d.0 > (XEN) [VT-D]dmar.c:383: endpoint: 0000:00:1a.0 > (XEN) [VT-D]dmar.c:676: RMRR region: base_addr 7ddb5000 end_address 7ddc1fff > (XEN) [VT-D]dmar.c:812: found ACPI_DMAR_ATSR: > (XEN) [VT-D]dmar.c:705: atsru->all_ports: 0 > (XEN) [VT-D]dmar.c:353: bridge: 0000:00:01.0 start=0 sec=1 sub=2 > (XEN) [VT-D]dmar.c:353: bridge: 0000:00:02.0 start=0 sec=3 sub=4 > (XEN) [VT-D]dmar.c:353: bridge: 0000:00:02.2 start=0 sec=5 sub=b > (XEN) [VT-D]dmar.c:353: bridge: 0000:00:03.0 start=0 sec=c sub=c > (XEN) [VT-D]dmar.c:353: bridge: 0000:00:03.2 start=0 sec=d sub=d > (XEN) [VT-D]dmar.c:817: found ACPI_DMAR_RHSA: > (XEN) [VT-D]dmar.c:757: rhsau->address: fbffc000 rhsau->proximity_domain: 0 > (XEN) Xen ERST support is initialized. > (XEN) HEST: Table parsing has been initialized > (XEN) Using ACPI (MADT) for SMP configuration information > (XEN) SMP: Allowing 12 CPUs (0 hotplug CPUs) > (XEN) IRQ limits: 48 GSI, 2272 MSI/MSI-X > (XEN) Switched to APIC driver x2apic_cluster. > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) Detected 2100.082 MHz processor. > (XEN) Initing memory sharing. > (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 > (XEN) mce_intel.c:735: MCA Capability: BCAST 1 SER 1 CMCI 1 firstbank 0 extended MCE MSR 0 > (XEN) Intel machine check reporting enabled > (XEN) alt table ffff82d0802dd990 -> ffff82d0802debd8 > (XEN) PCI: MCFG configuration 0: base 80000000 segment 0000 buses 00 - ff > (XEN) PCI: MCFG area at 80000000 reserved in E820 > (XEN) PCI: Using MCFG for segment 0000 bus 00-ff > (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB. > (XEN) Intel VT-d Snoop Control enabled. > (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. > (XEN) Intel VT-d Queued Invalidation enabled. > (XEN) Intel VT-d Interrupt Remapping enabled. > (XEN) Intel VT-d Shared EPT tables enabled. > (XEN) I/O virtualisation enabled > (XEN) - Dom0 mode: Relaxed > (XEN) Interrupt remapping enabled > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) ENABLING IO-APIC IRQs > (XEN) -> Using old ACK method > (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 > (XEN) TSC deadline timer enabled > (XEN) Platform timer is 14.318MHz HPET > (XEN) Allocated console ring of 128 KiB. > (XEN) mwait-idle: MWAIT substates: 0x1120 > (XEN) mwait-idle: v0.4 model 0x3e > (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff > (XEN) VMX: Supported advanced features: > (XEN) - APIC MMIO access virtualisation > (XEN) - APIC TPR shadow > (XEN) - Extended Page Tables (EPT) > (XEN) - Virtual-Processor Identifiers (VPID) > (XEN) - Virtual NMI > (XEN) - MSR direct-access bitmap > (XEN) - Unrestricted Guest > (XEN) - APIC Register Virtualization > (XEN) - Virtual Interrupt Delivery > (XEN) - Posted Interrupt Processing > (XEN) HVM: ASIDs enabled. > (XEN) HVM: VMX enabled > (XEN) HVM: Hardware Assisted Paging (HAP) detected > (XEN) HVM: HAP page sizes: 4kB, 2MB, 1GB > (XEN) Brought up 12 CPUs > (XEN) ACPI sleep modes: S3 > (XEN) mcheck_poll: Machine check polling timer started. > (XEN) Dom0 has maximum 816 PIRQs > (XEN) *** LOADING DOMAIN 0 *** > (XEN) elf_parse_binary: phdr: paddr=0xffffffff80200000 memsz=0x6b36cc > (XEN) elf_parse_binary: phdr: paddr=0xffffffff80ab36d0 memsz=0x1e2798 > (XEN) elf_parse_binary: memory: 0xffffffff80200000 -> 0xffffffff80c95e68 > (XEN) elf_xen_parse_note: GUEST_OS = "FreeBSD" > (XEN) elf_xen_parse_note: GUEST_VERSION = "0x10c923" > (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" > (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 > (XEN) elf_xen_parse_note: PADDR_OFFSET = 0xffffffff80000000 > (XEN) elf_xen_parse_note: ENTRY = 0xffffffff8078a000 > (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff80789000 > (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 > (XEN) elf_xen_parse_note: FEATURES = "writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel|hvm_callback_vector" > (XEN) elf_xen_parse_note: PAE_MODE = "yes" > (XEN) elf_xen_parse_note: unknown xen elf note (0xd) > (XEN) elf_xen_parse_note: LOADER = "generic" > (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x0 > (XEN) elf_xen_parse_note: BSD_SYMTAB = "yes" > (XEN) elf_xen_parse: using notes from SHT_NOTE section > (XEN) elf_xen_addr_calc_check: addresses: > (XEN) virt_base = 0xffffffff80000000 > (XEN) elf_paddr_offset = 0xffffffff80000000 > (XEN) virt_offset = 0x0 > (XEN) virt_kstart = 0xffffffff80200000 > (XEN) virt_kend = 0xffffffff80e1cea0 > (XEN) virt_entry = 0xffffffff8078a000 > (XEN) p2m_base = 0xffffffffffffffff > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0xffffffff80200000 -> 0xffffffff80c95e68 > (XEN) Dom0 symbol map 0xffffffff80c95e68 -> 0xffffffff80e1cea0 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000470000000->0000000472000000 (2087721 pages to be allocated) > (XEN) Init. ramdisk: 000000047fb29000->0000000480000000 > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff80200000->ffffffff80e1cea0 > (XEN) Init. ramdisk: ffffffff80e1d000->ffffffff812f4000 > (XEN) Phys-Mach map: ffffffff812f4000->ffffffff822f4000 > (XEN) Start info: ffffffff822f4000->ffffffff822f54b4 > (XEN) Page tables: ffffffff822f6000->ffffffff8230b000 > (XEN) Boot stack: ffffffff8230b000->ffffffff8230c000 > (XEN) TOTAL: ffffffff80000000->ffffffff82400000 > (XEN) ENTRY ADDRESS: ffffffff8078a000 > (XEN) Dom0 has maximum 4 VCPUs > (XEN) elf_load_binary: phdr 2 at 0xffffffff80200000 -> 0xffffffff808b36cc > (XEN) elf_load_binary: phdr 3 at 0xffffffff80ab36d0 -> 0xffffffff80b327f8 > (XEN) elf_load_bsdsyms: shdr 4 at 0xffff83047f28a308 -> 0xffffffff80c967b0 > (XEN) elf_load_bsdsyms: shdr 33 at 0xffff83047f9cc10a -> 0xffffffff80cc1180 > (XEN) elf_load_bsdsyms: shdr 34 at 0xffff83047f9ccbb8 -> 0xffffffff80cc1330 > (XEN) elf_load_bsdsyms: shdr 35 at 0xffff83047fa78bf0 -> 0xffffffff80d6d368 > (XEN) [VT-D]iommu.c:1421: d0:Hostbridge: skip 0000:00:00.0 map > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.2 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.3 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.4 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.5 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.6 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:04.7 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:05.0 > (XEN) Masked VT-d error signaling on 0000:00:05.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:05.2 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:00:05.4 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:16.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:16.1 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:1a.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:1d.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:1f.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:1f.2 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:1f.3 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:00:1f.6 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:01:00.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:01:00.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:03:00.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:03:00.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:03:00.2 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:03:00.3 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:07:00.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:07:00.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:07:00.2 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:07:00.3 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:09:00.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:09:00.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:09:00.2 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:09:00.3 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:0f:00.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:0f:00.1 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:11:04.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:08.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:09.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0a.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0a.1 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0a.2 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0a.3 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0b.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0b.3 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0c.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0c.1 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0c.2 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0d.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0d.1 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0d.2 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0e.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:0e.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:0f.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:0f.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:0f.2 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:0f.3 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:0f.4 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:0f.5 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.0 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.1 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.2 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.3 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.4 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.5 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.6 > (XEN) [VT-D]iommu.c:1435: d0:PCIe: map 0000:ff:10.7 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:13.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:13.1 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:13.4 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:13.5 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:16.0 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:16.1 > (XEN) [VT-D]iommu.c:1447: d0:PCI: map 0000:ff:16.2 > (XEN) [VT-D]iommu.c:730: iommu_enable_translation: iommu->reg = ffff82c000201000 > (XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs > (XEN) ........................done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: Errors and warnings > (XEN) Xen is relinquishing VGA console. > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) > (XEN) Freed 308kB init memory. > (XEN) error code 7 > (XEN) domain_crash_sync called from vmcs.c:1319 > (XEN) Domain 0 (vcpu#0) crashed on cpu#0: > (XEN) ----[ Xen-4.6-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: 0000:[] > (XEN) RFLAGS: 0000000000000200 CONTEXT: hvm guest > (XEN) rax: 0000000000000000 rbx: ffff82d0802e8000 rcx: ffff82d0802eff80 > (XEN) rdx: ffff82d0801e08a8 rsi: 0000000000000000 rdi: ffff82d0801ecb0c > (XEN) rbp: ffff82d080105fa6 rsp: ffffffff8230c000 r8: ffff8304741c0000 > (XEN) r9: ffff82d080106013 r10: ffff82d0802eff70 r11: 0000000000000000 > (XEN) r12: ffff82d0802eff50 r13: ffff830473fc9000 r14: ffff8304741c0000 > (XEN) r15: ffff82d08018e547 cr0: 0000000080000011 cr4: 0000000000000020 > (XEN) cr3: 00000000022f6000 cr2: 0000000000000000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0000 > (XEN) Guest stack trace from rsp=ffffffff8230c000: > (XEN) Fault while accessing guest memory. > (XEN) Domain 0 crashed: rebooting machine in 5 seconds. This looks like a Xen issue. AFAICT Xen fails to even start the Dom0 guest, so I don't think it's FreeBSD related. I'm CCing xen-devel, let's see if someone can provide more insight. Roger. From owner-freebsd-xen@FreeBSD.ORG Thu Apr 2 19:49:17 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EFA21BA for ; Thu, 2 Apr 2015 19:49:17 +0000 (UTC) Received: from os-mail-1.tamu.edu (os-mail-1.tamu.edu [165.91.23.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp-relay.tamu.edu", Issuer "InCommon RSA Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A96B9F1 for ; Thu, 2 Apr 2015 19:49:16 +0000 (UTC) X-TAMU-Auth-ID: None X-TAMU-SenderIP: 165.91.22.240 Received: from exchange.tamu.edu (exch-2p-snat-pool.tamu.edu [165.91.22.240]) by os-mail-1.itio.tamu.edu (8.14.7/8.14.7) with ESMTP id t32HxEkK022072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 2 Apr 2015 12:59:22 -0500 Received: from MB03.ads.tamu.edu ([169.254.3.105]) by caex02.ads.tamu.edu ([128.194.147.21]) with mapi id 14.03.0195.001; Thu, 2 Apr 2015 12:58:46 -0500 From: Andrew Daugherity To: "freebsd-xen@freebsd.org" Subject: Re: Poor performance with FreeBSD 10.1 under Xen 4.2 Thread-Topic: Poor performance with FreeBSD 10.1 under Xen 4.2 Thread-Index: AQHQaOOfinlni718o0SDQUrW328qGJ0yNL4AgAPWZYCABFQ6gA== Date: Thu, 2 Apr 2015 17:58:46 +0000 Message-ID: <5CC2ABAB-AE46-4C9F-A610-D4EAD735ECA0@tamu.edu> References: <115BE54D-078A-4C45-8904-861DAB316C03@tamu.edu> <5516A998.10206@citrix.com> <57429F3F-8CC9-4C4F-86DF-3E63C5853B01@tamu.edu> In-Reply-To: <57429F3F-8CC9-4C4F-86DF-3E63C5853B01@tamu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.194.89.247] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-04-02_06:2015-04-02,2015-04-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 kscore.is_bulkscore=1.00272401493129e-10 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.999586866343301 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.999586866343301 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.999586866343301 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1504020169 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 19:49:17 -0000 On Mar 30, 2015, at 6:52 PM, Andrew Daugherity wrote= : > On Mar 28, 2015, at 8:16 AM, Roger Pau Monn=E9 wro= te: >> I'm Ccing feld because IIRC he found something similar on one of his >> boxes, that also had VTx but no EPT (just like yours). Would it be >> possible for you to try the same set of tests on a different hardware? >=20 > I think you're on to something. I copied this FreeBSD 10.1 VM to a syste= m running the same version of Xen (and same SLES in the Dom0), but with an = Opteron 2360SE CPU (which has both SVM and NPT), and it is *much* faster (a= nd feels more responsive too): > [snip] >> Also, if even FreeBSD 10.1 compiled without XENHVM shows this issue it >> means there's something in the generic code that doesn't work well when >> running virtualized on this specific hardware, but I'm afraid figuring >> it out is not trivial. One place to start would be asking on >> freebsd-hackers and freebsd-virt. >=20 > I suppose this performance delta with presence of EPT/NPT vs. lack thereo= f means it's time to take it to those lists? My next step will be to test = 10.1 under KVM on the Xeon to confirm whether it's a Xen issue or strictly = EPT. It seems I spoke too soon. I booted into the "default" (non-Xen) Linux ker= nel on the Xeon E5420 box and launched the same FreeBSD 10.1 VM under KVM, = and performance is much, much better: Forked, executed and destroyed 5000 processes in 12.307276 seconds. [ Always remains at this time and does not become slower. ] sssd configure: 24.713u 13.530s 0:36.89 103.6% 5337+233k 434+298io 69pf+0w sssd build: 288.788u 235.076s 4:29.13 194.6% 3640+202k 233+28io 87pf+0w It may not be the Xen platform drivers at fault (since my NOHVM kernel didn= 't help), but something is causing FreeBSD 10.x to perform badly under Xen = on a CPU w/o EPT, whereas KVM does not have this issue. Full KVM dmesg follows at the end for comparison; I've highlighted some dif= ferences here. I wonder if any of the CPU/ACPI/timer differences are relev= ant? --- dmesg.xen 2015-03-27 18:06:12.000000000 -0500 +++ dmesg.kvm 2015-04-02 12:39:51.000000000 -0500 @@ -5,54 +5,55 @@ FreeBSD 10.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 -XEN: Hypervisor version 4.2 detected. -CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2493.90-MHz K8-class= CPU) - Origin =3D "GenuineIntel" Id =3D 0x10676 Family =3D 0x6 Model =3D 0x1= 7 Stepping =3D 6 - Features=3D0x1783fbff - Features2=3D0x81282201 +CPU: QEMU Virtual CPU version 1.4.2 (2493.82-MHz K8-class CPU) + Origin =3D "GenuineIntel" Id =3D 0x623 Family =3D 0x6 Model =3D 0x2 = Stepping =3D 3 + Features=3D0x783fbfd + Features2=3D0x80002001 AMD Features=3D0x20100800 AMD Features2=3D0x1 real memory =3D 1073741824 (1024 MB) -avail memory =3D 1010737152 (963 MB) +avail memory =3D 1010745344 (963 MB) Event timer "LAPIC" quality 400 -ACPI APIC Table: +ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs -FreeBSD/SMP: 1 package(s) x 2 core(s) +FreeBSD/SMP: 2 package(s) x 1 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 irqs 0-47 on motherboard + cpu1 (AP): APIC ID: 1 +ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized -xen_et0: on motherboard -Event timer "XENTIMER" frequency 1000000000 Hz quality 950 -Timecounter "XENTIMER" frequency 1000000000 Hz quality 950 -acpi0: on motherboard +acpi0: on motherboard acpi0: Power Button (fixed) -acpi0: Sleep Button (fixed) -acpi0: reservation of 0, a0000 (3) failed cpu0: on acpi0 cpu1: on acpi0 -attimer0: port 0x40-0x43 irq 0 on acpi0 -Timecounter "i8254" frequency 1193182 Hz quality 0 -Event timer "i8254" frequency 1193182 Hz quality 100 -atrtc0: port 0x70-0x71 irq 8 on acpi0 +atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 +hpet0: iomem 0xfed00000-0xfed003ff on acpi0 +Timecounter "HPET" frequency 100000000 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 -acpi_timer0: <32-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 +acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 [snip] +orm0: at iomem 0xef000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 +attimer0: at port 0x40 on isa0 +Timecounter "i8254" frequency 1193182 Hz quality 0 +Event timer "i8254" frequency 1193182 Hz quality 100=20 [more snipped] Any idea how to track this down? I suppose I should file a bug to keep tra= ck of this, but maybe wait until we narrow down the cause? Thanks, Andrew dmesg.kvm: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Copyright (c) 1992-2014 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.1-RELEASE-p6 #0: Tue Feb 24 19:00:21 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: QEMU Virtual CPU version 1.4.2 (2493.82-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0x623 Family =3D 0x6 Model =3D 0x2 S= tepping =3D 3 Features=3D0x783fbfd Features2=3D0x80002001 AMD Features=3D0x20100800 AMD Features2=3D0x1 real memory =3D 1073741824 (1024 MB) avail memory =3D 1010745344 (963 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 random: initialized acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 100000000 Hz quality 950 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xb008-0xb00b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,= 0x376,0xc060-0xc06f at device 1.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 uhci0: port 0xc000-0xc01f irq 11 at = device 1.2 on pci0 usbus0: controller did not stop usbus0 on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xfc000000-0xfdffffff,0xfebf0000-0xfe= bf0fff at device 2.0 on pci0 vgapci0: Boot video device virtio_pci0: port 0xc020-0xc03f mem 0xfebf1000= -0xfebf1fff irq 11 at device 3.0 on pci0 vtnet0: on virtio_pci0 virtio_pci0: host features: 0x719fffe3 virtio_pci0: negotiated features: 0x308fbbe3 vtnet0: Ethernet address: 52:54:00:7d:be:ff virtio_pci1: port 0xc040-0xc05f irq 10 at devi= ce 5.0 on pci0 vtballoon0: on virtio_pci1 virtio_pci1: host features: 0x71000002 virtio_pci1: negotiated features: 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse Explorer, device ID 4 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: console (9600,n,8,1) orm0: at iomem 0xef000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x100> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 attimer0: at port 0x40 on isa0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 fdc0: No FDOUT register! ppc0: cannot reserve I/O port range Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 device ada0: Serial Number QM00001 ada0: 16.700MB/s transfers (WDMA2, PIO 8192bytes) ada0: 6144MB (12582912 512 byte sectors: 16H 63S/T 12483C) ada0: Previously was known as ad0 random: unblocking device. SMP: AP CPU #1 Launched! Root mount waiting for: usbus0 uhub0: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/ada0p2 [rw]...= From owner-freebsd-xen@FreeBSD.ORG Fri Apr 3 21:37:19 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC5C5351 for ; Fri, 3 Apr 2015 21:37:19 +0000 (UTC) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "relay.upc.es", Issuer "TERENA SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 604D274F for ; Fri, 3 Apr 2015 21:37:18 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id t33KdWE7013828 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=FAIL) for ; Fri, 3 Apr 2015 22:39:32 +0200 Received: from [192.168.2.134] (193.Red-81-35-2.dynamicIP.rima-tde.net [81.35.2.193]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id t33KdUPs024504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 3 Apr 2015 22:39:31 +0200 Message-ID: <551EFA82.9070007@entel.upc.edu> Date: Fri, 03 Apr 2015 22:39:30 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleg==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-xen@freebsd.org Subject: Unable to boot with the dom0 xen kernel Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: ACL matched, not delayed by milter-greylist-4.4.3 (violet.upc.es [147.83.2.51]); Fri, 03 Apr 2015 22:39:32 +0200 (CEST) X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.4.3 (ackerman2.upc.es [147.83.2.244]); Fri, 03 Apr 2015 22:39:32 +0200 (CEST) X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 21:37:19 -0000 Hi, I'm trying to test xen but after following the instructions here: http://wiki.xen.org/wiki/FreeBSD_Dom0 the machine is unable to boot. I see the FreeBSD loader, giving me the traditional options, after the timeout I see it loads the kernel and modules (basically opensolaris.ko and zfs.ko) and then, instead of showing the me boot info as usual, the machine shows me a cursor for a while and then reboots. The test machine is an i7-3540M. The FreeBSD version is: FreeBSD 11.0-CURRENT #4 r279875+f0e745a(HEAD): Sat Mar 14 16:55:11 CET 2015 and I'd say EPT and IOMMU are available: # [gus@portgus /usr/home/gus]$ dmesg|grep EPT VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID # [root@portgus /usr/home/gus]# acpidump -t | grep DMAR DMAR: Length=184, Revision=1, Checksum=194, I tried booting with verbose, but it did the same, the machine tried to boot and then it rebooted. The laptop does not have a ttyu1 (com1) port. Does this affect? I wonder why I don't see any message in the console. Is that because of the xen_cmdline option in the loader? Would it be useful if get trace via the video or serial consoles? If so, how I do get those traces, by tweaking the xen_cmdline option? Best, Gustau From owner-freebsd-xen@FreeBSD.ORG Sat Apr 4 15:12:39 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3B25FCE for ; Sat, 4 Apr 2015 15:12:39 +0000 (UTC) Received: from mail.ultra-secure.de (mail.ultra-secure.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0EB2AA for ; Sat, 4 Apr 2015 15:12:38 +0000 (UTC) Received: (qmail 36480 invoked by uid 89); 4 Apr 2015 15:12:31 -0000 Received: from unknown (HELO ?192.168.1.200?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 4 Apr 2015 15:12:31 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Poor performance with FreeBSD 10.1 under Xen 4.2 From: Rainer Duffner In-Reply-To: <5CC2ABAB-AE46-4C9F-A610-D4EAD735ECA0@tamu.edu> Date: Sat, 4 Apr 2015 17:12:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <115BE54D-078A-4C45-8904-861DAB316C03@tamu.edu> <5516A998.10206@citrix.com> <57429F3F-8CC9-4C4F-86DF-3E63C5853B01@tamu.edu> <5CC2ABAB-AE46-4C9F-A610-D4EAD735ECA0@tamu.edu> To: Andrew Daugherity X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-xen@freebsd.org" X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2015 15:12:40 -0000 > Am 02.04.2015 um 19:58 schrieb Andrew Daugherity = : >=20 > On Mar 30, 2015, at 6:52 PM, Andrew Daugherity = wrote: >> On Mar 28, 2015, at 8:16 AM, Roger Pau Monn=E9 = wrote: >>> I'm Ccing feld because IIRC he found something similar on one of his >>> boxes, that also had VTx but no EPT (just like yours). Would it be >>> possible for you to try the same set of tests on a different = hardware? >>=20 >> I think you're on to something. I copied this FreeBSD 10.1 VM to a = system running the same version of Xen (and same SLES in the Dom0), but = with an Opteron 2360SE CPU (which has both SVM and NPT), and it is = *much* faster (and feels more responsive too): >> [snip] >>> Also, if even FreeBSD 10.1 compiled without XENHVM shows this issue = it >>> means there's something in the generic code that doesn't work well = when >>> running virtualized on this specific hardware, but I'm afraid = figuring >>> it out is not trivial. One place to start would be asking on >>> freebsd-hackers and freebsd-virt. >>=20 >> I suppose this performance delta with presence of EPT/NPT vs. lack = thereof means it's time to take it to those lists? My next step will be = to test 10.1 under KVM on the Xeon to confirm whether it's a Xen issue = or strictly EPT. >=20 > It seems I spoke too soon. I booted into the "default" (non-Xen) = Linux kernel on the Xeon E5420 box and launched the same FreeBSD 10.1 VM = under KVM, and performance is much, much better: >=20 Hi, I have access to Xen at work (and will continue to do so - we intend to = use and offer FreeBSD in our =84Cloud=93-platform (Apache CloudStack). AFAIK, we have no KVM. Just Xen. Unfortunately, I=92ve got little time currently, but I will try to get a = VM where I can run this during the next week. I will also collect the hardware-details of the host (AFAIK, we=92ve got = HP DL380G8 servers with lots of RAM and two CPUs). Rainer