WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH][RESEND]Nvram patch for IA64

To: "Yu, Ke" <ke.yu@xxxxxxxxx>, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, "Christian Limpach" <christian.limpach@xxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH][RESEND]Nvram patch for IA64
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 31 Oct 2006 11:46:27 -0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Huang, Xinmei" <xinmei.huang@xxxxxxxxx>
Delivery-date: Thu, 02 Nov 2006 13:37:30 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acbwn3GTeQX7YqjuSrWHsAKaEOOOQwANzaogAF+2ZZACaGUm0AAEkMSwAAbrrDAAAklb1wAAHUJQABe5ZSAAFQfgUA==
Thread-topic: [Xen-devel] [PATCH][RESEND]Nvram patch for IA64
> Ian Pratt  write on 2006?10?30? 22:23:
> >>> The data is dynamic, so I am afraid it is hard to store 
> NVRAM data 
> >>> in domain config.
> >> 
> >> There must be a possible static good configuration to allow you to 
> >> boot Oses you care about? Do changes happen during guest execution 
> >> that you really care about preserving across reboots?
> 
> Yes, static good configurations can be made for different 
> guest OS (RHEL, SLES, Win 2003, Win Vista). But I am afraid 
> this workaround will have potential issue, because we are 
> unable to predict how guest OS would use variable. 

Is the variable contents the same for all installs of each of the OSes
you list?
 
> > Further, storing it in a file will create compilcations 
> when we move 
> > to running qemu in stub domains -- we'll need a way of passing it 
> > across xenbus.
> 
> Could you please elaborate what the "complications" is? Per 
> my understanding, even without NVRAM file, qemu in stub 
> domain still need to read/write the disk image file.

You won't be able to write stuff to a file directly, you'll need to use
a front/back driver, which is needlessly complicated. xenbus is
definitely the way to go.

> It is also OK to store NVRAM in xenstore, but seems xenstore 
> have no capability to store binary data, it can only store 
> null-termincated strings.  If we want to directly store EFI 
> variable in xenstore instead of sotre NVRAM binary, we need 
> to para-virtualize guest firmware GetVariable/Setvariable 
> interface, which is more complicated. 

You'll have to escape the NULLs. It might be easiest just to store the
hex string.

You don't need to paravirtulize it as qemu can do the trivial
conversion.

Ian


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel