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

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> 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