Implement a simpler interface for the hypercalls to ACM. I put the
parameters to all hypercalls into a union. On top of this I have
implemented a shim layer for enabling ACM hypercalls on PPC.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
domain builder and in to python code.
This knowledge will be useful to allow us to pre-seed the protocol
field in a VBD entry in xenstore which will allow us to run older
kernels in a 32on64 mixed environment.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
and remove the use of xc_vcpu_getcontext() from HVM save/restore.
Also fixes loss of CR2, DR6 and DR7 contents across HVM save/restore.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
Not working yet as we are a bit too keen to kill the qemu-dm process,
before we know that the save has been successful.
Signed-off-by: Keir Fraser <keir@xensource.com>
into xc_domain_save, like we did for xc_domain_restore
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
--HG--
rename : tools/libxc/xc_linux_save.c => tools/libxc/xc_domain_save.c
Share privregs with domain and assign it to pseudo physical
address space as para virtualized domain.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
into one function (and one file) since they share a lot of code
Signed-off-by: Tim Deegan <Tim.Deegan@øensource.com>
--HG--
rename : tools/libxc/xc_linux_restore.c => tools/libxc/xc_domain_restore.c
since it doesn't mean that any more. This is a sticking-plaster
to get HVM S/R working until the proper memory-map handling patch
is ready.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
It is no longer being maintained and probably shouldn't have existed in the
first place, since it was almost identical to xc_linux_build.c.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
Instead of kludging a max_gpfn estimate in shared_info, add a new
XENMEM command to discover the actual maximum gpfn value as known by
the shadow code.
This needs to be more robust when we support HVM ballooning in future
anyway. One interesting point is that max_gpfn may be close to 4GB
even for small-memory HVM guests since for example SVGA LFB is mapped
into the I/O hole. We may need to special case the I/O hole somehow,
or provide some finer-grained way to find out which parts of the GPFN
space are actually used (e.g., get Xen to fill in a bitmap with 1 bit
per 1024 pages, or similar).
Signed-off-by: Keir Fraser <keir@xensource.com>
Change common Xen code to start all VCPUs (except idle ones)
offline. Change arch code to deal with this.
Signed-off-by: Keir Fraser <keir@xensource.com>
So far the order isn't specified and may be random in theory.
But sorted array is requested by crash utility for efficient search.
Fortunately it is the case except ia64 full virtualized domain.
Update document such that those array must be sorted and fix the ia64
full virtualized domain case.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
