From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VnQ79-0001Ev-3O for mharc-grub-devel@gnu.org; Mon, 02 Dec 2013 04:48:27 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnQ6y-0001Ae-5U for grub-devel@gnu.org; Mon, 02 Dec 2013 04:48:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnQ6s-00035H-SV for grub-devel@gnu.org; Mon, 02 Dec 2013 04:48:15 -0500 Received: from smtp02.citrix.com ([66.165.176.63]:25517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnQ6s-00035B-NC for grub-devel@gnu.org; Mon, 02 Dec 2013 04:48:10 -0500 X-IronPort-AV: E=Sophos;i="4.93,809,1378857600"; d="scan'208";a="77246629" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 02 Dec 2013 09:48:08 +0000 Received: from [10.80.2.80] (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Mon, 2 Dec 2013 04:48:07 -0500 Message-ID: <1385977687.7108.11.camel@kazak.uk.xensource.com> Subject: Re: [Xen-devel] pvgrub2 is merged From: Ian Campbell To: Andrey Borzenkov Date: Mon, 2 Dec 2013 09:48:07 +0000 In-Reply-To: <20131129214427.02439ae0@opensuse.site> References: <527EA084.6000706@gmail.com> <20131129132422.GC16321@riva.ucam.org> <20131129214427.02439ae0@opensuse.site> Organization: Citrix Systems, Inc. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.2.80] X-DLP: MIA1 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 66.165.176.63 Cc: grub-devel@gnu.org, "xen-devel@lists.xen.org" X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:48:22 -0000 On Fri, 2013-11-29 at 21:44 +0400, Andrey Borzenkov wrote: > В Fri, 29 Nov 2013 13:24:22 +0000 > Colin Watson пишет: > > > On Sat, Nov 09, 2013 at 09:52:20PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > > > Hello, all. pvgrub2 has just became part of upstream grub as ports > > > i386-xen and x86_64-xen. > > > > Could anyone offer packaging advice for which ports should be built > > here? Is it reasonable to assume that a 32-bit userspace only needs the > > 32-bit Xen port and a 64-bit userspace only needs the 64-bit Xen port, > > or is it possible that there could be cross-architecture combinations > > here? Does the architecture of the GRUB port have to match the > > architecture of the Xen hypervisor? > > > > I guess this question is better asked on xen-devel. Assuming we have 64 > bit dom0 and try to boot 32 bit domU. Is it possible to start with > loading 64 bit grub that loads 32 bit kernel and jumps to it? If yes > (and in other direction too) situation becomes relatively simple. AIUI it is not in general possible for a 32-bit PV guest to convert itself to 64-bit or vice versa, which is essentially what would have to happen to boot the other type of kernel. So once you have selected the grub binary to use it cannot boot the other type of kernel. (Yes, this is an annoying technical restriction...) It is however possible to run 32-bit and 64-bit guests on a 32-bit dom0 with a 64-bit underlying hypervisor. It is also possible to run both types of guest on a 64-bit kernel and 64-bit underlying hypervisor. So, for packaging purposes it would be best to provide both 32- and 64-bit grub binaries for both 32- and 64-bit userspace. > > For those familiar with Debian packaging, I'm trying to work out whether > > it's sufficient to just build grub-xen{,-bin,-dbg} packages which would > > be i386-xen on i386 and x86_64-xen on amd64, or whether I have to have > > two variants on each architecture the way I do for EFI. All other > > things being equal I'd prefer to keep the package count as low as > > possible, but only if that won't break real-world use cases. Sorry! > For a long time I dream of possibility to mark grub platform packages > as noarch (speaking about RPM) - they *are* noarch from the OS PoV. I > was told that was impossible, but may be I should try once more. That does sound like a good idea. Ian.