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

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

Ian Pratt  write on 2006?10?31? 22:45:
>>>> 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.
> 
> But do all installs of the same OS have the same variable contents?
> That was the question.

Oh, I misunderstand your question. Yes. The same OS installation have same 
variable contents.  

> 
>>>>> 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.
> 
> Break it into 64 byte (128 character) chunks and only populate nodes
> that are not all ones.
> 
> Ian

OK. then the xensotor content will looks like this:
nvram = " "                                          # nvram dir
   vti-domain1 = " "                               # domain name
       0 = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  # 128 characters, data offset = 0*64
       1 = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  # 128 characters, data offset = 1*64
       .........                                          # skip data block of 
all 0xff 
   vti-domain2 = " "
       ..........


Best Regards
Ke

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