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>
returning the error to the caller.
None of our vmcs reads/writes should fail. In fact many callers were
ignoring failures, which can hide bugs (in fact it hid one in
vmx_restore_dr(), which was incorrectly using __vmread() before
the vmcs was loaded).
__vmread_safe() is used by the vmcs dump function, which is the only
function which can legitimately fail a vmcs access.
Signed-off-by: Keir Fraser <keir@xensource.com>
external-device-migrate script in its handling of parameters.
Patch from Roland Illig <roland.illig@gmx.de>.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
across a reboot regularly. Inside _refresh, there is the occasion for new
domains to appear, if an existing domain reboots itself. In this case, we
need to get the list of running domains from Xen again.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Tim Deegan
kaf24@firebug.cl.cam.ac.uk
Ewan Mellor
kfraser@localhost.localdomain
Ian Campbell
Alastair Tse
jfehlig@jfehlig2.provo.novell.com