use bus_dmamap_load_mbuf() et.al.
due to XENPV override, _BUS_BUS_TO_PHYS() dmamap segment ds_addr
gets filled with ma, so value can be directly used for e.g. grant calls
Goal: save/restore support in NetBSD domUs, for i386, i386 PAE and amd64.
Executive summary:
- split all Xen drivers (xenbus(4), grant tables, xbd(4), xennet(4))
in two parts: suspend and resume, and hook them to pmf(9).
- modify pmap so that Xen hypervisor does not cry out loud in case
it finds "unexpected" recursive memory mappings
- provide a sysctl(7), machdep.xen.suspend, to command suspend from
userland via powerd(8). Note: a suspend can only be handled correctly
when dom0 requested it, so provide a mechanism that will prevent
kernel to blindly validate user's commands
The code is still in experimental state, use at your own risk: restore
can corrupt backend communications rings; this can completely thrash
dom0 as it will loop at a high interrupt level trying to honor
all domU requests.
XXX PAE suspend does not work in amd64 currently, due to (yet again!)
page validation issues with hypervisor. Will fix.
XXX secondary CPUs are not suspended, I will write the handlers
in sync with cherry's Xen MP work.
Tested under i386 and amd64, bear in mind ring corruption though.
No build break expected, GENERICs and XEN* kernels should be fine.
./build.sh distribution still running. In any case: sorry if it does
break for you, contact me directly for reports.
- 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@).
As we want some control on the name the backend driver will have we
can't use autoconf(9) here. Instead backend drivers registers to
xenbus, which will call a create callback when a new device is there.
Backend devices won't have a "struct device" in xenbus, use a void pointer
instead.
- keep a linked list of xenbus_device in the xenbus_infrastructure, and
keep a pointer to struct device for each xenbus_device
- xenbus_probe_device_type(): check that the device is not already attached
- when we get a frontend_changed callback, call xenbus_probe_device_type()
- When a device changes to state XenbusStateClosed, config_detach() it
and free the structures.
While there, move xbusd_path[] to the end of struct xenbus_device, and
allocate only the space needed to store the path. Garbage-collect
struct xenbus_driver, it's not needed.
