that I committed in changeset 5303:d68bc64e2cfe38a85483a8c5d349b4ee45e91fb9
This fixes some very weird and nasty Xen crashes.
Signed-off-by: Keir Fraser <keir@xensource.com>
In VMX decoder, we always assume the 2 operands of x86 instructions are
in the same length, however, MOVZ is an exception.
This patch fixes MOVZ instruction handling.
Signed-off-by: Xin Li <xin.b.li@intel.com>
Signed-off-by: Dan Xu <dan.d.xu@intel.com>
cpu_present map. This prevents domU SMP kernels without HOTPLUG_CPU
support from booting. Secondary cpus need to be present and online
before init/main.c:do_basic_setup() calls init_workqueues() (which
initializes per-cpu workqueues).
Without this patch, non HOTPLUG_CPU enabled kernels hang when flushing
cpu workqueues as the spinlock in the structure is never initialized (it
has a default value of zero which means the lock has been acquired on
x86).
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
Signed-off-by: Keir Fraser <keir@xensource.com>
>can reproduce the condition when debug isn't on. The monitor_table is
>not zeroed when entering alloc_monitor_pagetable() - this happens when I
>create a vmx guest. I'm not sure why this happening at first glance.
>File: xen/arch/x86/shadow32.c
>Line: 689
>System: VT/VMX FC3 x86_32 (I can reproduce on FC4 x86_64 too)
>ASSERT(pagetable_get_paddr(v->arch.monitor_table) == 0);
Solution:
What happens is that the monitor page table is not zeroed out
during the initial setup for VMX guests. As a result, at a later
time when we enable shadow mode for these VMX guests, we trip on
the ASSERT problem above. To fix this, we just need to initialize
the monitor page table to 0 before calling vmx_final_setup_guest()
and enabling shadow mode.
on vncserver or remote X. Changeset 7547 added a test of
opts.vals.display when getenv("DISPLAY"); because there is a default
value:localhost:0, that causes the test always to be true.
Signed-off-by: Xiaofeng Ling <xiaofeng.ling@intel.com>
The problem is: There is no mechanism to detect block device setup failure
Network devices have the same problem, and are fixed with this too.
I handling this problem in the way suggested by aliguori:
- hotplug scripts write a "hotplug-status" node on store
- Xend DevController.createDevice() check verify this node and return success
or throw an exception on failure.
- If no changes in "hotplug-status" node after DEVICE_CREATE_TIMEOUT seconds
Xend throw an exception showing the problem with hotplug scripts.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Currently, on a machine with RAM above 4G, we can not run 32bit VMX
guest on x86_64 xen, the root cause is that the PAE page table PDPT must
below 4G, this patch fixes this issue.
Signed-off-by: Xin Li <xin.b.li@intel.com>
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
watch being added to the watch list in register_xenbus_watch(). Fixed
by adding the watch to the list unconditionally, and remove it in the
error case.
Watch events may get lost, the xenstored response races against the new
watch being added to the watch list in register_xenbus_watch(). Fixed
by adding the watch to the list unconditionally, and remove it in the
error case.
That one fixes the network issues I'm seeing. Due to the race the
"online" hotplug event for the vif backend was lost sometimes.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
be enabled and disabled dynamically while the system is running. The
existing DOM0_TBUFCONTROL hypercall is used, and three new operations
have been added: enable, disable, and set_size. This is to address
concerns that use of the trace buffers impacts system performance.
The initial value of opt_tbuf_size is set to zero, so that trace
buffers remain disabled by default. They can be enabled as they used
to be, by adding tbuf_size= to the xen command line at boot time. They
can also be turned on and off any time when the system is running. The
size of the trace buffer allocation can also be changed dynamically
while the system is running. The trace buffers may be completely
deallocated by setting the size to zero. No change in buffer size can
be done while tracing is enabled;
Other Changes made:
- Update the constants in tools/xentrace/formats to match those in
public/trace.h
- libxc functions for enable/disable, get/set size
Still left to do:
- remove all ifdef's for trace buffers and the 'trace' build option
- xm command to do enable/disable trace buffers and get/set size
Signed-off-by: Rob Gardner <rob.gardner@hp.com>
