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

["Yu, Ke" <ke.yu@xxxxxxxxx>]

Ian Pratt  write on 2006?10?31? 19:46:
>> 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?

No, different OS has differrent configurations.

> 
>>> 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
 
OK. this should work. Then the only concern is the size of NVRAM. 64KB data is 
quite large for xenstore. Is it acceptable to xenstore? Maybe qemu need to 
compress the data first. Usually, most of the NVRAM content is free area, which 
is continuous byte "0xFF", so compresion can reduce the size significantly.

Best Regards
Ke

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