From owner-freebsd-virtualization@freebsd.org Tue Feb 14 11:07:25 2017 Return-Path: Delivered-To: freebsd-virtualization@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E74E6CDF04B for ; Tue, 14 Feb 2017 11:07:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 BCB48130F for ; Tue, 14 Feb 2017 11:07:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v1EB7O7E098699 for ; Tue, 14 Feb 2017 11:07:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-virtualization@FreeBSD.org Subject: [Bug 211746] [Hyper-V] UEFI VM can't boot from the iso installation disk Date: Tue, 14 Feb 2017 11:07:25 +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: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: decui@microsoft.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 11:07:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211746 --- Comment #9 from Dexuan Cui --- (In reply to Marcel Moolenaar from comment #6) Differences between the maps are: 1) In the first red rectangle, we can see 48MB memory (0x3000 pages) is allocated from ConvventionalMemory to LoaderData and this is the expected correct behavior. 2) In the second red rectangle, we can see 4 pages are allocated, probably = by the firmmare itself. I guess we can ignore this. 3) No other difference except the above. So, Hyper-V's AllocatePages should be correct. :-) But there is indeed some BootServicesData memory starting at 0x2f73000 with 0x118d pages (i.e. starting at 47.449 MB with the length =3D=3D 17.55MB)!!! "elf64_exec() -> trampoline() -> efi_copy_finish -> *dst++ =3D *src++;" tri= es to overwrite the memory between 2MB and 2+48=3D50MB, and we get the crash -- I= guess Hyper-V has some mechanism to prevent the guest from writing into that BootServideData memory block. With STAGE_PAGES <=3D 45MB, we don't touch that BootServiceData memory bloc= k due to the fact 2+45 < 47.449 and hence we don't get the crash. Now, it looks to me this is a bug of FreeBSD? It looks the hardcoded macro for the 2MB kernel base is LOADER_ADDRESS. I g= uess it's not easy to make it a runtime dynamic value, but we should have a long term plan to fix this. And can we have a short term workaround for Hyper-V? e.g. making STAGE_PAGES a dynamic variable and using 45MB if the loader detecets the underlying hypervisor is Hyper-V??? :-) Thanks Marcel for the effective help and let's brainstorm. --=20 You are receiving this mail because: You are the assignee for the bug.=