From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from list by lists.gnu.org with archive (Exim 4.71)
	id 1VrRiO-0001ov-7t
	for mharc-grub-devel@gnu.org; Fri, 13 Dec 2013 07:19:32 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60373)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <phcoder@gmail.com>) id 1VrRiE-0001YI-3l
	for grub-devel@gnu.org; Fri, 13 Dec 2013 07:19:30 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <phcoder@gmail.com>) id 1VrRi5-0007UQ-Lm
	for grub-devel@gnu.org; Fri, 13 Dec 2013 07:19:22 -0500
Received: from mail-ee0-x234.google.com ([2a00:1450:4013:c00::234]:57844)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <phcoder@gmail.com>) id 1VrRi5-0007UH-B3
	for grub-devel@gnu.org; Fri, 13 Dec 2013 07:19:13 -0500
Received: by mail-ee0-f52.google.com with SMTP id d17so821448eek.25
	for <grub-devel@gnu.org>; Fri, 13 Dec 2013 04:19:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=message-id:date:from:user-agent:mime-version:to:subject:references
	:in-reply-to:content-type;
	bh=PRQtSCCZtzCPV1gi9rOjrkGD5sdi9iELwTaCrjo5dMM=;
	b=z/5Qq1PA196Jk7MTtz7Jh45yzm1heh6ZvfGseElbHYY2yDp4Kq3Av32a2PwS46cXK2
	44u3Iu7P2UCndElbHom585b2iutlLkuCJbJMhcVue/oc4/auftnxCwqcIsS2TV0Crcqo
	ZcH43VnkjF+E3sEG+NjA71QXluAJY/aOW8G6HDGKbcY95irYix6WpyuFXXP2JtOZmfCx
	uG0byz1cgLkKT4nYdEf6jqJi7oiJo0/61c9U0ymtCgyDgwzKd2N89LX0tmf/R+T3kurC
	PhK8p9Fhr6tNSd2N0OuJgeqXUaXeGuEoHr4RP97shPfIplxom7y7RUb2Bk01z9jlQrxM
	2iiw==
X-Received: by 10.15.23.206 with SMTP id h54mr2564652eeu.17.1386937152571;
	Fri, 13 Dec 2013 04:19:12 -0800 (PST)
Received: from [192.168.1.16] (85-188.196-178.cust.bluewin.ch.
	[178.196.188.85])
	by mx.google.com with ESMTPSA id a51sm6188858eeh.8.2013.12.13.04.19.10
	for <multiple recipients>
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 13 Dec 2013 04:19:11 -0800 (PST)
Message-ID: <52AAFB37.4070100@gmail.com>
Date: Fri, 13 Dec 2013 13:19:03 +0100
From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?=
	<phcoder@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: The development of GNU GRUB <grub-devel@gnu.org>, 
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH 3/4] Build grub.xen.
References: <20131212153643.GA1431@riva.ucam.org>
	<20131212153741.GD1431@riva.ucam.org>
	<20131213115643.GJ1431@riva.ucam.org>
In-Reply-To: <20131213115643.GJ1431@riva.ucam.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature";
	boundary="FMDSnQQR6duCSb3ExtVhX3PakUopl93HO"
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
	(bad octet value).
X-Received-From: 2a00:1450:4013:c00::234
X-BeenThere: grub-devel@gnu.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: The development of GNU GRUB <grub-devel@gnu.org>
List-Id: The development of GNU GRUB <grub-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/grub-devel>,
	<mailto:grub-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/grub-devel>
List-Post: <mailto:grub-devel@gnu.org>
List-Help: <mailto:grub-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/grub-devel>,
	<mailto:grub-devel-request@gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Dec 2013 12:19:30 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--FMDSnQQR6duCSb3ExtVhX3PakUopl93HO
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 13.12.2013 12:56, Colin Watson wrote:
> On Thu, Dec 12, 2013 at 03:37:41PM +0000, Colin Watson wrote:
>> +if [ -z "$grub_xen_guest" ]; then
>> +	# This is the copy of grub.xen installed in the dom0's filesystem.
>> +	# Look for a copy in the domU's filesystem and chainload that.  This=

>> +	# allows us to guarantee that GRUB will be in sync with the
>> +	# configuration file in the domU.  The file locations here must not
>> +	# have any configure-generated substitutions applied, as the intent
>> +	# is that a single grub.xen should be able to cope with a variety of=

>> +	# domU systems.
>> +	if search --set=3Droot --file /boot/grub/grub.xen; then
>> +		linux /boot/grub/grub.xen grub_xen_guest=3D1
>> +		boot
> [...]
>=20
> I talked about this with Ian Jackson in the pub last night.

>  We came to
> the same conclusion more or less at the same time, that this is in fact=

> a new boot protocol; since it essentially just expects a bzImage here,
Not a bzimage but ELF, optionally compressed/wrapped in bzimage.
> there's nothing to stop somebody for example putting a bare kernel
> there.
Yes, this is a possibility. You'd have to comile the options in it though=
=2E
> We'd like people to be able to set up PV-GRUB2 in their dom0s
> even for domUs that aren't new enough to have PV-GRUB2 inside them.
Yes, that's why I spoke about compatibility. But it's good that this
subject is explicitly discussed.
The main problem with this is security, as discussed in unprivileged
partition subthread. The best way is to replicate pvgrub1 behaviour for
such systems.
> Furthermore we'd like to be able to arrange that PV-GRUB (Legacy) and
> PyGRUB can at least in principle use the same boot protocol; in the cas=
e
> of PV-GRUB that would presumably involve a stub menu.lst, but it
> shouldn't take much more than that.
The legacy_configfile would need adjustments for that. PVGRUB1 used hdX
notation for virtual disks which legacy_configfile just maps to hdX.
This is a mess because even on runtime it's not obvious how disks are
mapped, it may even differ between pvgrub1 versions.
>  As such the file name in the domU's
> filesystem shouldn't be GRUB-specific, although per Vladimir it'd be
> good for it to be distinct for each architecture.
>=20
Agreed. But if we save it, it should contain full xen device name,
partition specification (beware that partition numbering is ambiguous
and if you use partition number you have to specify how it's counted.
Otherwise you may opt to have some kind of static specification where to
locate the file. Using a special partition for this is an option and if
so, IMO, it's better to share it with EFI system partition.
> I'll put this patch series on hold for the time being (with the possibl=
e
> exception of "search --exclude", which I think has been uncontroversial=

> so far and could perhaps be merged as a generally-useful gadget?)
I didn't review it for the reasons of clarifying intended usage. It has
problems, I'll answer in its thread.
> and
> write this up as a proper protocol document for inclusion in xen.git.
> Ian said he'd like to get this into Xen 4.4's documentation.  No change=
s
> to Xen code are required as far as I know.
>
Ok, could we be kept in the loop on the drafts? I'd hate to have to cope
with yet another ambiguous protocol specification.




--FMDSnQQR6duCSb3ExtVhX3PakUopl93HO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iF4EAREKAAYFAlKq+z0ACgkQmBXlbbo5nOti7wD+NSErxTbHlYCdFRw9lzyciuXD
xP2Nk9ofoPP2hQiHJ3IA/19JeBQMTLe06RoVhkm1LeDrFi9IwmH6RsI+/3JT6z/l
=ndHx
-----END PGP SIGNATURE-----

--FMDSnQQR6duCSb3ExtVhX3PakUopl93HO--