- add BEST_SUSPENDED macro, the xennet equivalent of BLKIF_STATE_SUSPENDED
for xbd (indicate that backend is in suspended state)
- use GNTST_okay to check the grant table setup status returned by hypercall,
rather than 0
No functional changes.
pseudo-physical and machine frame numbers.
- add HYPERVISOR_crash() for i386 and amd64. Intended to be used by a domain
to notify Xen that it crashed on purpose, and request a dump (if applicable).
No functional changes intended.
Reviewed by Christoph (cegger@).
- change unbind_[pv]irq_from_evtch() so that they now return the event
channel the [PV]IRQ was bound to. It reflects the opposite behaviour of the
bind_[pv]irq_to_evtch() functions.
- remove xenbus_suspend() and xenbus_resume() prototypes, as they are not
used anywhere else, and will conflict with the xenbus pmf(9) handlers.
- make start_info aligned on a page boundary, as Xen expects it to be so.
- mask event channel during xbd detach before removing its handler (can
avoid spurious events).
- add the "protocol" entry in xenstore during xbd initialization. Normally
created during domU's boot by xentools, it is under domU's responsibility
in all other cases (save/restore, hot plugging, etc.).
- modifications to xs_init(), so that it can properly return an error.
Reviewed by Christoph (cegger@).
- fix and add comments
- make some panic/error messages more relevant
- remove last '\n' in DPRINTK() macros, not required as it is already part of format string.
No functional changes.
but use the map's protection bits, as the hypervisor may refuse read/write
mappings for some entries. Now suspend/resume of domUs should work
from a NetBSD dom0, provided that the domU's kernel supports it.
From Jean-Yves Migeon.
> xm list
Domain-Unnamed 1 467 1 ---s-- 46.0
The root cause is a discrepancy in the error *value* codes:
BSD uses the AT&T Unix Version 6 error codes, while Xen uses
Unix System V error codes (or actually what Linux/i386 has taken over from it).
After shutting down (or rebooting) a domU, the guest container gets destroyed.
This implies freeing resources used by the guest (RAM, internal management structures, etc.).
The destroy process is an asynchronous process in order to not block the Dom0 (and other DomUs).
The destroy process works this way:
The XEN_DOMCTL_destroydomain is invoked from the xentools (python, libxc code).
XEN_DOMCTL_destroydomain hypercall calls domain_kill().
domain_kill() calls domain_relinquish_resources().
domain_relinquish_resources() calls relinquish_memory().
relinquish_memory() calls hypercall_preempt_check().
hypercall_preempt_check() makes all this asynchronous.
It fails, if there's an other hypercall pending.
In that case relinquish_memory() returns EAGAIN, which means, just retry to continue the destroy process.
EAGAIN is passed through the return path back into the python code
(= userspace). The python code checks for EAGAIN and *should*
retry, but it didn't.
In Unix System V / Linux, EAGAIN has the error code value 11.
In BSD, EAGAIN has the error code value 35 and EDEADLK has the error code value 11.
This means, Xen returning EAGAIN means for the python code EDEADLK.
This lead to the confusing error message 'domain destroy failed due to Resource Deadlock avoided'.
We finally convert the error code from the Xen hypercall to BSD before passing it upstream.
Since we have to treat 0x0 as a valid page, this got broken in rev. 1.26.
Introduce INVALID_PAGE as magic value and restore the check.
This unbreaks IOCTL_PRIVCMD_MMAPBATCH while allowing to launch HVM guests.
hvm: Avoid need for ugly setcpucontext() in HVM domain builder by
pre-setting the vcpu0 to runnable inside Xen, and have the builder
insert a JMP instruction to reach the hvmloader entry point from
address 0x0.
So we have to treat guest physical address 0x0 like every one
or we end in a page fault loop when launching a HVM guest, otherwise.
XXX Keep this for Xen2 as this change hasn't been tested there.
for ioapics and faked up for others. Add it to "struct ioapic_softc"
for now, until device/softc get split.
This required all typecasts between "struct pic" and "struct ioapic_softc"
to be replaced, I hope I got them all.
functionally tested on i386, compile-tested on xen, untested on amd64
