which fills in multicall arguments for __HYPERVISOR_update_va_mapping
and __HYPERVISOR_update_va_mapping_otherdomain dealing with
differences between i386 and amd64.
Fix problem where packets would be duplicated, possibly looping, when
a domU is doing IP routing.
Problem reported and fix tested by Mike M. Volokhov on port-xen
While there, add some __predict_false/true in conditionnals where
appropriate, remove a always-true test, and fix handling of
mbuf shortage.
- kernel (both dom0 and domU) boot, console is functionnal and it can starts
software from a ramdisk
- there is no driver front-end expect console for domU yet.
- dom0 can probe devices and ex(4) work when Xen3 is booted without acpi
and apic support. But the on-board IDE doens't get interrupts.
The PCI code still needs work (it's hardcoded to mode 1). Some of this
code should be shared with ../x86
The physical insterrupt code needs to get MPBIOS and ACPI support, and
do interrupt routing to properly interract with Xen.
To enable Xen-3.0 support, add
options XEN3
to your kernel config file (this will disable Xen2 support)
Changes affecting Xen-2.0 support (no functionnal changes intended):
- get more constants from genassym for assembly code
- remove some unneeded registers move from start()
- map the shared info page from start(), and remove the pte = 0xffffffff hack
- vector.S: in hypervisor_callback() make sure %esi points to
HYPERVISOR_shared_info before accessing the info page. Remplace some
hand-written assembly with the equivalent macro defined in frameasm.h
- more debug code, dissabled by default.
while here added my copyright on some files I worked on in 2005.
Always call HYPERVISOR_fpu_taskswitch() at the end of npxsave_lwp().
This fixes the FPU problems detected by paranoia on a NetBSD/Xen guest.
Based on patch sent by Paul Ripke on port-xen, but reworked by me.
Should fix port-xen/30977.
kernel by x86 platforms (instead of a simple char *). This way, the code
in, e.g., lookup_bootinfo, is a bit easier to understand.
While here, move the lookup_bootinfo function used in x86 platforms (amd64,
i386 and xen) to a common file (x86/x86_machdep.c), as it was exactly the
same in all of them.
- add a buch of PCI storage devices
- add firewire devices
- add some missing PCI network devices
- add serial and parallel PCI adapters
- add lpt0 at isa
- add com1 at isa
com0 not added for the benefit of serial console users (it will conflicts
with the Xen kernel).
XXX this means that setups with serial console on com1 will now break with the
default kernel.
Use userconf(4) (add -c to kernel command line) or change your setup to
com0 instead (most bios allows arbitrary mappings of com ports)
- move copyin and friends from locore.S to their own file, copy.S.
share it between i386 and xen.
- defparam KERNBASE and kill KERNBASE_LOCORE hack.
- add more symbols to assym.h and use it where appropriate.
- rather than embedding bufq_state in driver softc,
have a pointer to the former.
- move bufq related functions from kern/subr_disk.c to kern/subr_bufq.c.
- rename method to strategy for consistency.
- move some definitions which don't need to be exposed to the rest of kernel
from sys/bufq.h to sys/bufq_impl.h.
(is it better to move it to kern/ or somewhere?)
- fix some obvious breakage in dev/qbus/ts.c. (not tested)
xennetback instances. To support this, more fields from xni_page to xni_pkt.
This would also have the effect to move more code into the
while (!SLIST_EMPTY(&pkt_page->xni_pkt_head)) loop in xennetback_tx_free().
By passing xni_pkt instead of xni_page to xennetback_tx_free we can
avoid the loop, and the xni_pkt_head list completely. There is even a sligh
performance increase if the domU deals with xni_txring->event properly.
Based on comments from YAMAMOTO Takashi.
In theory mbufs can have an infinite life time and could block the transmit
ring (as slots are released when the mbuf external storage is freed). To
avoid this, when we're processing the last slot of the ring copy the buffer
and release the slot immediatly.
