This gets rid of a warning on some GCC versions
Signed-off-by: Jimi Xenidis <jimix@watson.ibm.com>
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
--HG--
extra : transplant_source : j%9A%E4%9A%3B%FE%5E%2B%F2%FC%FF%3A%17%9A%1CU%83%86%3D%F1
Remove xc_ia64_get_pfn_list() from setup_guest() in xc_linux_build.c,
use xc_domain_populate_physmap() and xc_domain_translate_gpfn_list().
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
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>
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>
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>
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>
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>
kaf24@localhost.localdomain
Jimi Xenidis
awilliam@xenbuild.aw
kfraser@localhost.localdomain
Ewan Mellor
Alastair Tse
Tim Deegan
kaf24@firebug.cl.cam.ac.uk
john.levon@sun.com
jfehlig@jfehlig2.provo.novell.com