[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> >> 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.
> 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"? 

See xenbits.xensource.com/ext/xen-api.hg

Various parts of a domain's runtime config are persisted in a database,
and the nvram state could be added to this. There's no good example to
copy as the nvram state is unusual in that its written by both qemu
rather than the control tools. Xenbus watchers let you do this, though.

> Does xenstore
> has the interface to write data outside of xenstore. 

You can register a watcher to be told when someone writes to a section
of the store then arrange to persist the data. You can add this to xend.

> 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.

No extra ring buffer is needed or wanted.

Ian


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.