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>
First, only save the bits that can be set, so that on a subsequent
read can't see MBZ bits as set. Next, be sure to initialize the
timer_divide_count, which is derived from the TDCR. This avoids a
potential divide-by-zero elsewhere in the code.
The original patch was provided by Ben Thomas <ben@virtualiron.com>.
This modified version refactors the code slightly and renames
timer_divide_count to timer_divisor.
Signed-off-by: Keir Fraser <keir@xensource.com>
Based on a patch from Xin Li <xin.b.li@intel.com>. Changed
significantly on the Xen side -- not as cut down as the original
patch: this one keeps the xen_event_channel 'API' unchanged.
Signed-off-by: Keir Fraser <keir@xensource.com>
Protocol changes:
* There is a new operation (BLKIF_OP_WRITE_BARRIER)
to pass on barrier requests.
* There is a new state (BLKIF_RSP_EOPNOTSUPP) to indicate
unsupported operations (barrier writes may fail depending
on the underlying block device).
* A new xenstore node named "feature-barrier" indicates the
backend is able to handle barrier writes. The value can
be 1 (all is fine) or 0 (underlying block device doesn't
support barriers).
blkback changes: Add "feature-barrier" node to indicate barrier
support, pass incoming barrier requests to the block layer using
submit_bio(WRITE_BARRIER, bio). Some error handling fixes to
properly pass through barrier write failures, so the frontend
can turn off barriers then.
blkfront changes: Check if the backend sets "feature-barrier", if
present switch to QUEUE_ORDERED_DRAIN mode. Send off barrier
requests to the backend using the new BLKIF_OP_WRITE_BARRIER
operation. Also some error handling for the EOPNOTSUPP case.
Background: Barriers are needed to make journaling filesystems work
reliable. For some requests they need order constrains to make the
transactions work correctly. Barrier requests are used to pass that
ordering information to the block layer and/or to the device, so the
constrains are obeyed when reordering requests for better write
performance.
Signed-off-by: Gerd Hoffmann <kraxel@suse.de>
expected.
Now that xm list outputs the real system memory allocation, this can
be 1-2MB less than expected.
Signed-off-by: Alastair Tse <atse@xensource.com>
conservative wrt the ACPI region. hvmloader should fix up
by freeing unused memory in the range 0xE0000-0x100000.
Signed-off-by: Keir Fraser <keir@xensource.com>
Don't step off the end of the line, or delete characters that aren't there.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>
The bug occurs when the guest is entering protected mode and reaches
the far jump to set up the 32-bit segment registers for the virtual
VMENTER we're about to perform. vmxassist, in protected_mode(), looks
at the segment registers, which might be 16-bit segments or might be
32-bit segment selectors at this stage (depending on whether the OS
has reloaded them since entering protected mode); and it tries to load
the segments from the GDT. Unconditionally. Even if the segment
register still actually contains a real mode 16-bit segment. Whoops.
vmxassist already has code to detect 16-bit segments that survived
unmodified from a transition into and out of protected mode, and to
save and restore those appropriately. It does this using
"saved_rm_regs", which get cleared on entry to protected mode, and
then set to the old segment value if we fail to set a given 32-bit
segment correctly.
The fix is to save the 16-bit segments *always*, on entry to protected
mode when %CR0(PE) is first set; and to clear the saved 16-bit segment
and set the 32-bit variant in oldctx whenever a 32-bit segment
descriptor is set during the transition to 32-bit CS. Then, when we
finally do the VMENTER, we will set up the VMCS from only the 32-bit
segments, clearing the VMCS entries for segments that have not been
assigned valid 32-bit segments yet.
Tested on various RHEL-5 boot.isos, including ones which worked before
and ones which triggered the bug; all now boot correctly.
Signed-off-by: Stephen Tweedie <sct@redhat.com>
Now users will see the following error:
[root@bebop ~]# xm create -c 128
Using config file "/etc/xen/128".
Error: Device 51713 (tap) could not be connected.
/tmp/128.img does not exist
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Remove the additional XMLRPC calls per domain just to get system
memory and instead make sure we update that value and return it via
the SXP that gets returned when xm list is called.
Signed-off-by: Alastair Tse <atse@xensource.com>
(immediately after the domain is created). QEMU needs this in place when it
starts up, in order to find the VNC password.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
kfraser@localhost.localdomain
Alastair Tse
Ian Campbell
Tim Deegan
kaf24@firebug.cl.cam.ac.uk
Ewan Mellor