This should fix the assertions people have been seeing
in domU blkfront where we run out of IDs (because they
were being shared by multiple vbds).
Signed-off-by: Keir Fraser <keir@xensource.com>
all register parameters are clobbered on return. Furthermore,
multicall arrays are clobbered on return from a multicall (only the
result field can be trusted!).
These restrictions are enforced by debug builds of Xen in the
following ways:
1. On completion of a multicall, the call array is overwritten
with garbage before writing in the result fields.
2. On completion of a hypercall, all parameter registers are
overwritten with garbage.
Signed-off-by: Keir Fraser <keir@xensource.com>
unpin", which is already implemented for x86_32. Since we now only pin
the root rather than any of the other levels, the overall performance
became better especially with workloads that require heavy memory
management operations.
On 8-way x86_64 xenlinux (dom0) the kernel build was improved by about
10% (using make -j32). Even a small setup like a UP HT system, I see
about 3% performance gain with kernel build (make -j4).
Lmbench also shows improvements in fork/exec/sh:
Processor, Processes - times in microseconds - smaller is better
--------------------------------------------------------------------
Host OS Mhz null null open slct sig sig fork exec sh =20
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ---- ---- ---- ----=20
Linux 2.6.12- 3786 1.13 1.36 3.93 6.04 10.5 1.43 4.33 536. 1446 3614
Linux 2.6.12- 3786 1.13 1.36 3.91 6.03 10.4 1.44 4.38 346. 1050 2831
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Fix the tools/vnet makefiles so that vnets will compile
and includes updates to the vnet implementation.
Vnet ids are increased to 128 bits. The vnet module will
insmod whether xen-br0 exists or not.
Signed-off-by: Mike Wray <mike.wray@hp.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
The removal of 'xm call' to call a xend interface function directly
made the xend vnet functions inaccessible. This patch adds those functions
to xm and fixes the persistence in XmVnet to use xenstore.
Signed-off-by: Mike Wray <mike.wray@hp.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
pause should not only wait for the running flag to clear,
but also for the scheduler lock to be released. Also get
rid of some unused sync_lazy_execstate functions.
Signed-off-by: Keir Fraser <keir@xensource.com>
Use a collector and new flag for Xen version information, to avoid the
extra hypercall if the caller does not want the information.
Reference the xenstat_handle in the xenstat_node for ease of access
later, and update collectors accordingly.
Signed-off-by: Josh Triplett <josht@us.ibm.com>
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
The root cause of bug 169 is, machine_to_phys_mapping, starting from
0xffff800000000000, is mapped using 2M pages. When the system has RAM
no more than 2G, only one 2M page is allocated and only one PDE entry is
created correspondingly, so calling mfn_to_pfn with mfn > 0x80000 will
overflow this 2M page and cause a unable handled kernel paging request.
The mfn > 0x80000 comes from PCI device I/O memory, here from AGP
display card when booting X server. Jun suggested to use something like
get_user() when accessing machine_to_phys_mapping.
Signed-off-by: Xin Li <xin.b.li@intel.com>
2. Update scripts/vif-bridge to not call 'brctl delif'
When a domU is shutdown/destroyed and the netif is destroyed, the
notify_call_chain triggered from unregister_netdevice() will trigger the
bridge event handler and which will call the proper code to remove the
device from the bridge.
I can't see any reason why brtcl delif should be called when taking out
a domain if the call chain will delete the interface from the bridge
when the vif is destroyed automatically.
Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
