[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH][RESEND]Nvram patch for IA64
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |