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

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

Ian Pratt  write on 2006?10?31? 23:33:
> 
> In which case, wouldn't it just be a whole lot simpler to have qemu-dm
> know about these constants and just have a configuration parameter to
> cause it to serve up the right one when asked?
> 
> We probably should have a 'guest_type' field in the guest config
> anyway as we'll likely want to use this for enabling/tuning various
> optimizations.
> 
> I know this isn't ideal from a purist virtualization point of view,
> but it seems like a practical solution.

Since we know the final solution will be storing the nvram through xenbus, and 
this is not complex, I'd prefer to directly work out the final solution.

> 
>> 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 = " "
>>        ..........
> 
> We'll have to think about how this data gets persisted (I'd trigger a
> watcher and store it outside of xenstore). Look at the xen-api.hg tree
> to see how stuff gets persisted.
> 
> Ian

I am not familiar with the xan-api project, so could you please give more info 
on "trigger a watcher and store it outside of xenstore"? Does xenstore has the 
interface to write data outside of xenstore. Or do you mean having a separate 
thread to watch, and the thread will write data outside of xenstore. In this 
way, qemu should have ringbuffer to pass the data to the thread.

Best Regards
Ke

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