This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues)

To: Alex Williamson <alex.williamson@xxxxxx>
Subject: Re: [Xen-ia64-devel] New tree issues (domU restartanddomVTibootissues)
From: Tristan Gingold <tgingold@xxxxxxx>
Date: Fri, 15 Jun 2007 07:08:14 +0200
Cc: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>, xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 14 Jun 2007 22:01:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1181825329.6221.632.camel@bling>
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
References: <823A93EED437D048963A3697DB0E35DE59E6E9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1181825329.6221.632.camel@bling>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Thu, Jun 14, 2007 at 06:48:49AM -0600, Alex Williamson wrote:
> On Thu, 2007-06-14 at 13:04 +0800, Zhang, Xing Z wrote:
> > >
> > >   What if you have multiple vbds exported to the domain?  Exporting a
> > >CD is an obvious case where you'll have to parse the disk list to guess
> > >a unique path.  What if you boot multiple guests from the same
> > >read-only, live image (like a knoppix copied to disk)?  This seems more
> > >troublesome than naming the nvram file using the domain name.  What
> > >collisions do you foresee with domain names?  Seems like the ideal
> > >scenario would be to save the nvram on the EFI partition
> > >(/efi/xen/nvram).  Maybe the libfsimage functionality used by pygrub
> > >would make this possible.
> > [Zhang, Xing Z] 
> > Yes, image path makes things trouble. Thanks for your mention. The
> > collision only encountered when you use a same configure file to boot
> > different images(I am afraid people will do that in developing period).
> > EFI partition(/efi/xen/nvram)? I am not sure what you mean. Is it dom0's
> > partition?
>    No, I was thinking we might store the nvram in the EFI partition of
> the HVM guest.  pygrub already has some support for finding an
> elilo.conf in the guest EFI partition, parsing it and pulling out the
> kernel and initrd for PV guests.  I'm wondering if a similar method
> could be used to read and write the NVRAM image into the guest's EFI
> partition.
Humm, this seems slightly over-kill for me.
A simpler approach would be to create a dedicated partition for the NVRAM

>    I'm not sure my read-only image scenario makes any sense, and this
> approach would suffer the same issue with one nvram store per EFI
> partition.  I don't know if that's an unreasonable limitation or not.
> The thing I like about storing the nvram in the guest image is that it's
> self contained.  The guest image could be copied to another system and
> the nvram would be there with it.  I also don't know if libfsimage has
> support to create and later write /etc/xen/nvram file as it's typically
> only used to read out of the boot partition.
>    I can see now why you wanted to store the nvram based on disk image
> path, it's a similar idea to storing the nvram in the guest EFI
> partition.  If the nvram is stored in the dom0 fs, using domain name
> seems like the easiest approach, but I still like the idea of having the
> nvram stored in the guest image.

I don't really like the idea of saving NVRAM on the disk.  Real machines
don't do that so why should we do that.
If you really want to save NVRAM, an EFI tool can do the work.


Xen-ia64-devel mailing list