Many of the changes to entry.S can be removed because we don't support
CONFIG_PREEMPT anymore.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
at the local end of the xenbus connection (i.e. that value that is passed
through xenbus_switch_state). This means that xenbus_probe can wait for all
the boot devices to become ready without having to hurt the store.
Also, fix this probing -- previously, the wrong value was being returned by
all_devices_ready_, so this polling would only have waited for one device.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
proceed. This avoids the race (bug #549) that would result in the infamous
VFS: Cannot open root device "sda1" or unknown-block(0,0) message even when
the hotplug layer had succeeded to configure the device.
Note that The Infamous Message has many possible root causes -- this change
only fixes one of them. This particular root cause is characterised by
successful boots interleaved with unsuccessful ones, and diagnose.py showing
both front and backend drivers in the Connected state.
Closes bug #549.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
This seems a more reliable method since it seems that we always trust the base address
and we don't need to work around renumbering/rebasing as we do with APICIDs.
This is an alternative to the Yonah networking patch from Allen Kay at Intel.
Signed-off-by: Keir Fraser <keir@xensource.com>
- fixes a problem in the vTPM backend where the timer was killed when
the timer function was run
- removes a variable from being put in the ring by the frontend
- reformatting due to indent tool running over some of the files
Has been tested with the vtpm-relevant parts of xm-test.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
- machine_specific_memory_setup() was unused on x86-64
- machine_specific_modify_cpu_capabilities() must not be __init (for CPU hotplug)
- machine_specific_modify_cpu_capabilities() should be called in similar ways on 32- and 64-bits
From: Jan Beulich <JBeulich@novell.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
truncates the range, and then reads/writes page-wise until possibly
encountering a -EFAULT issue, Xen code accessed the whole range in a
single step, thus not allowing partially succeeding accesses.
From: Jan Beulich
Signed-off-by: Keir Fraser <keir@xensource.com>
need for a hypercall in the guest timer interrupt handler.
Cleaned up stolen/blocked tick handling in Linux.
Signed-off-by: Keir Fraser <keir@xensource.com>
exported by Xen. This is based heavily on a patch from Rik van Riel, but
extended to distinguish between idle/blocked cycles and stolen cycles.
There is still stuff todo:
1. Xen should export the time values in shared memory, to save a hypercall
on every time interrupt (even though that is only every 10ms, worst case).
2. As in s390, Xen's cputime_t should be measured at finer granularity than
jiffies. Nanoseconds would be a better unit.
3. Break out the internals of the account_steal_time() interface so that we don't
need to abuse it so wretchedly.
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
uses slow iret path every time (but most returns will do that
anyway, since they'll be to userspace). Fast return (to kernel)
can be implemented inside the macro and respect the
supervisor_mode_kernel feature flag.
Signed-off-by: Keir Fraser <keir@xensource.com>
