Beginning a sprean clean of the USB code.
Lots of cleanups and fixes (thanks to Harry Butterworth for pointing out several
locking and allocation errors).
Signed-off-by: mark.williamson@cl.cam.ac.uk
More x86_64 progress: currently churning through construct_dom0.
Then will need a few extensions to entry.S and I can jump to ring 3.
To get hypercalls working I will need a SYSCALL entry point and also
to add uaccess.h/usercopy.S functionality.
Signed-off-by: keir.fraser@cl.cam.ac.uk
Merge planb.cl.cam.ac.uk:/auto/anfs/scratch/scramble/kaf24/xen-2.0-testing.bk
into planb.cl.cam.ac.uk:/auto/anfs/scratch/scramble/kaf24/xen-unstable.bk
Move domain builder to be subarch-specific. Fix pfn_info structure and
page reference-counting to be 64-bit clean.
Signed-off-by: keir.fraser@cl.cam.ac.uk
Interface to typed allocator is now just xmalloc/xmalloc_array/xfree.
_xmalloc/_xmalloc_array are dead (or, at least, non-API).
Signed-off-by: keir.fraser@cl.cam.ac.uk
More x86_64 work. Interrupts and exceptions are now working. Next step is
DOM0 construction. First part of that is to map rest of physical memory,
allocate and map the mach_to_phys table, and fix arch_init_memory().
Signed-off-by: keir.fraser@cl.cam.ac.uk
Merge labyrinth.cl.cam.ac.uk:/auto/groups/xeno-xenod/BK/xen-unstable.bk
into labyrinth.cl.cam.ac.uk:/auto/groups/xeno/users/iap10/xeno-clone/xen-unstable.bk
slab.c in Linux is not a very nice piece of code: the version in Xen has
been hacked a certain amount and is not a vision of beauty either.
Given how rare and non-time-critical dynamic allocations are in Xen,
this replaces the 1800-line slab.c with a 160-line malloc.c which is
written as simply as possible for future enhancement.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (authored)
Signed-off-by: ian.pratt@cl.cam.ac.uk
Slab caches for things allocated only on initialization seems to be
overkill. This patch replaces them with the previous typesafe
allocator.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (authored)
Signed-off-by: ian.pratt@cl.cam.ac.uk
A typesafe allocator submitted by Rusty Russel with trivial renames by me.
Signed-off-by: Rusty Russel <rusty@rustcorp.com.au> (authored)
Signed-off-by: ian.pratt@cl.cam.ac.uk
Small hack to make CROMMULTISESSION ioctl return success rather than enosys, like we did on Xen 1.2.
From: Anthony Liguori aliguori@us.ibm.com
Signed-off-by: ian.pratt@cl.cam.ac.uk
Create the e820 map dynamically. This makes it easy to run VMX guests
of different memory sizes (no need to manually edit the e820 map).
Signed-off-by: Xin B Li <xin.b.li@intel.com>
Signed-off-by: Arun Sharma <arun.sharma@intel.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Right now, the memory for the 1:1 physical mode page tables comes from the
VMX domain's memory. With this change, when the user asks for a domain with
M Megabytes of memory, we actually allocate M+N megabytes in xend, where
N is the memory for the page table pages.
This simplifies the code in the device models that maps guest memory (we
now map all of it) and the E820 map can also give the full M megabytes to
the guest.
Signed-off-by: Xin B Li <xin.b.li@intel.com>
Signed-off-by: Arun Sharma <arun.sharma@intel.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
More x86/64. Status: traps.c now included in the build, but actual building
of IDT doesn't happen, and we need some sort of entry.S. More page-table
building required so that arch_init_memory() can work. And there is something
odd with MP-table parsing; I currently suspect that __init sections are
causing problems.
Signed-off-by: keir.fraser@cl.cam.ac.uk
Allow specification of backend vif MAC addresses. If a backend
MAC is not provided, generate one as before
Signed-off-by: Jody Belka <knew-xen@pimb.org>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Fix the device number calculation for /dev/hd* device names;
ide device numbering works differently to scsi
Signed-off-by: Jody Belka <knew-xen@pimb.org>
Signed-off-by: ian.pratt@cl.cam.ac.uk
More bootstrap fixes for x86/64. Next thing to do is sort out the IDT and
get traps.c working; then we can get rid of a bunch of dummy labels from
end of boot/x86_64.S. We're also going to need some kind of entry.S before
we can safely enable interrupts. Also bear in mind that not all of physical
RAM may be mapped (only first 1GB) and no m2p table is yet allocated or
mapped. Plenty to be done!