On different systems I ran into different build failures that can be
made more understandable by adding appropriate -devel package
installation checks.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
On i386-PAE, clear_fixmap() results in ill use of set_pte(). In all
contexts, p2m translations shouldn't occur here. Note that this is not
really an issue on native linux, as there is
(a) no pfn-to-mfn translation and
(b) __set_fixmap() takes an unsigned long physical address rather than
a paddr_t, which makes it so that bits 32 and up of the physical
address are always zero, permitting either order store when
clearing the entry.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
It is much more dangerous than domain_crash() because it
stops execution of teh current context regardless of
current state (e.g., IRQs disabled, locks held).
The preferred method to crash a domain is domain_crash()
and error return to the caller.
Signed-off-by: Keir Fraser <keir@xensource.com>
the guest but deleted by dom0 were remaining accounted against the guest,
which meant that the guest would eventually run out of quota.
This patch also prevents unprivileged domains from changing the owner of a
node. One guest could attack another by creating nodes and then transferring
them to the ownership of another, and though the accounting could be made to
work properly in this case, domains should never be transferring nodes in any
case, so it seems safer just to disallow the operation entirely.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
When console=ttyS0 in guest grub configuration and serial='pty' in vmx
configure file. The root cause to this bug is the characteristic of
PTY emulator in Qemu. PTY has write/read end with some buffer. Write
to a buffer will be failed after the buffer is full until read end
reads the data from buffer.
Previous to changeset 12026, write to serial port would fail quietly
when buffer for pty is full. With changeset 12026, write to serial
port would retry 3 times in 300ms if failed, even without notifying
guest using serial irq. Smp guest will hang, waiting for an
interrupt. For SMP guest, a watchdog thread should be executed
periodically, otherwise soft lockup is detected. With this patch, an
upper threshold of total consecutive retries is added and serial
interrupt would be sent after retry 3 times for each write request,
even if failed.
Signed-off-by: Xinmei Huang <xinmei.huang@intel.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
have the build fail for some trivial x86 specific assembly. I snagged the
appropriate bitops for ia64 and ppc (untested) and tossed in an
unoptimized option as well in case we want to make use of it.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
In certain cases, when a client doesn't have enough permissions, the
errno variable is not set in xenstored_core.c before its value is
reported back. As a result, the client can learn about the errno of
the last failed request to xenstored (which could have come from
another client). (An unintended information channel! :-)
From: Magnus Carlsson <magnus@galois.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
the (physical) CPU this was executing on did not get its multicall
state cleared and would reject any further multicalls, likely leading
to crashing dom0 at some point.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Introduce a new elfnote that specifies the lower boundary the kernel
wants to tolerate for the hypervisor hole.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
taken, as (significantly) increasing the runtime (without introducing
failures) can be considered a regression. This patch adds a block like:
====
Xm-test timing summary:
Run Started : Fri, 10 Nov 2006 14:53:18 +1100
Run Stopped : Fri, 10 Nov 2006 14:53:20 +1100
====
to the generated report.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
As currently physical mapping only reaches the initial reservation,
we're unable to balloon up to more than mem (even when maxmem > mem)
in any situation.
Signed-off-by: Glauber de Oliveira Costa <gcosta@redhat.com>
It was causing compatibility issues across architectures as
on x86 the effect would not persist across a continuation. On
x86/64 and powerpc (both of which use xencomm) the effect would
persist. This patch sidesteps the whole issue.
Signed-off-by: Keir Fraser <keir@xensource.com>
Barrier support was rewritten after 2.6.15. Perhaps it would be
possible to implement support for old kernels as well but for now it
is easier to just disable them.
Signed-off-by: Ian Campbell <ian.campbell@xensource.com>
Mainly this involves placing appropriate barriers before
updating the shared state variable, and after reading from it. The
model is that it is state switches that drive the transfer of data to
and fro in the shared ioreq structure. So writers should wmb() before
updating the variable; readers should rmb() after seeing a state
change.
These barriers aren't actually required given the current code
structure since the communication flow is really driven by
event-channel notifications, which happen to provide a sufficient
barrier. However, relying on this for all time and on all
architectures seems foolish and the barriers have negligible cost
compared with the totoal ioreq round-trip latency. Also the model of
communications being driven by the shared-memory state variable more
closely matches other inter-domain protocols (where there is usually a
shared-memory producer index), and is hence a model we are familiar
with and likely to implement correctly.
Signed-off-by: Keir Fraser <keir@xensource.com>
64bit libext2fs can have __u64 defined as unsigned long long,
while a uint64_t is unsigned long, and GCC complains.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
