Change /proc/xen/xsd_mfn to /proc/xen/xsd_kva containing the kernel
virtual address of the dom0 xenstore page. Update xenstored to use
/proc/xen/xsd_kva.
Signed-off-by: Keir Fraser <keir@xensource.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
(http://www.netlib.org/scalapack/). It should probably be xenstore-ls
a) for namespacing and b) to match up with the other xenstore commands
better.
Signed-off-by: Jeremy Katz <katzj@redhat.com>
remove and recreate the /local directory, but the manual_node call only works
if the tdb is empty -- we must use create_node, otherwise the store is
corrupted.
It's not clear to me that the other manual_node calls are safe, but I have only
made this smaller change for the sake of stability. These other calls should
be reviewed.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
the permission checking in xenstored.
Default the store permissions to read/write nobody (apart from the privileged
domain). Create a /local node with these permissions, ready for inheriting by
children. In Xend, create a /vm node with these permissions too, for the same
reason, and set the permissions on /local/domain/<domid> and each device
backend path to allow the guest domain to access these paths appropriately.
Added xstransact.{set_permissions,SetPermissions,mkdir,Mkdir,complete} as
support facilities.
This closes bug #290.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
/var/lib/xenstored. Closes bug #400. This fix no doubt has a performance hit,
so I have opened bug #401 to discuss a better fix.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
whether a domain has been introduced to the store. Added a separate message
XS_IS_DOMAIN_INTRODUCED and API for that (xs_is_domain_introduced) to determine
whether the domain has really been introduced. This change means that the
tools can determine the correct domain path earlier in the domain creation
process, which is particularly a factor with live migration, as it allows us
to create the devices earlier in the process, and unpause the new domain before
performing the introduce. Until recently we already had these features, but
the simplification of the interface between xend and xenstored caused breakage.
No longer clear out the domain path when a domain is introduced -- this was a
hack to work around the recent problematic semantics of GetDomainPath.
Do not write the contents of the info block to the store. All the configuration
info is written to the /vm path, and anything else in the info block is either
dealt with explicitly or is ephemeral and has no place in the store.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
recreation semantics.
Remove the unpause at the end of xc_linux_restore, and move it to
XendDomainInfo. This is necessary because xenstored now allocates the domain
path when the domain is introduced, which means that the new domain cannot
start running until that introduce is performed and the new devices
configured.
Give restore a separate completion phase in which domain details are stored.
This is required because the domain path is no longer available until after
the introduceDomain call.
TODO: Split the domain introduction into two so that the domain path is
available earlier. At the moment, the domain <-> store channel details are
passed in to xenstored when the domain is introduced, but in the case of
restore it is necessary to wait until the restore is completed before the
channel MFN is available.
Change the interface between XendDomainInfo and XendCheckpoint/image to not
have hideous callbacks through setConsoleRef and setStoreRef. Instead,
image.createImage explicitly returns those values, and XendCheckpoint passes
them through to completeRestore.
Move the purging of the domain path corresponding to a new domain from Xend
to xenstored, since xenstored is now in charge of this path. With the domain
path creation moved to xenstored, Xend cannot remove the path, because watches
may have fired on it already.
Fix the printf statement in xenstored in verbose mode that details the
messages being written. This statement was printing the buffer using %s, but
this buffer has an explicit length field, so we were seeing garbage after the
correct details.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Redirect all output to a buffer and only print the buffer once the
transaction succeeds, discarding output from previous attempts.
In particular, fixes failures when the (block) backend driver would
not configure because reads from the hotplug script did get double
output when a transaction had to be redone.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
that loop completely -- the xc_init_store, initDomainStore calls can all go.
Have xenstored understand where the local domain information goes. Xend no
longer has to generate a path and pass it to xenstored through
xs_introduce_domain -- we just allow xenstored to generate the path, and then
call GetDomainPath later. There is still some work required to tidy this up.
Change the uuid module to generate uuids as lists of bytes, not in the
stringified form. Added a unit test for that module.
Change the semantics of Xend restart, relying on these changes to the
xenstored semantics and earlier changes to add an opaque handle to the
hypervisor's domain-specific data block. The semantics are now clearer, as
Xend can validate whether the details in the store match the current live
domain.
Added a usage statement to xenstored.
Some of this code is by Steven Hand.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
for other inter-domain comms (power-of-two-sized rings, and
free-running indexes). The interface is defined in the spirit of
the console protocol, so maybe some chance of merging them
together later?
Signed-off-by: Keir Fraser <keir@xensource.com>
work if the transaction caused a retry, because optind had been obliterated.
Achieve this by splitting the main body of the loop off to a separate function,
meaning that we get rid of the goto out at the same time.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
time a watch is registered. Before this it is fine for
caller threads to read the comms channel directly as no
async messages will be received.
This avoids various user tools needlessly creating three
threads where one will do the job.
Signed-off-by: Keir Fraser <keir@xensource.com>
