This patch add CPU hot-add in system.
a) It mark all CPU as possible when booting, if CONFIG_HOTPLUG_CPU is
set. BTW, this will increase per_cpu area.
b) When a CPU is added through hypercall, the CPU will be marked as
present and offline, and the numa information is setup if numa is
supported. The CPU will be brought to online by dom0 online explicitly.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
This patch change the XENPF_get_cpuinfo interface to pass only one
pcpu information each hypercall. Also, it replace
xenpf_resource_hotplug with XENPF_cpu_online/offline.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Alphabetize object files and guest config options for better
readability. Also remove svm interrupt prototypes which do not
exist.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
XenAPI (not xapi) has supported only LUN assignment mode for pvSCSI.
But at last, HOST assignment mode also is supported by these patches.
To support HOST assignment mode, these patches add PSCSI_HBA class
and DSCSI_HBA class to XenAPI.
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
No populate-on-demand activities should happen when a domain is dying.
Especially, it is a bug for memory to be added to the PoD cache when
d->is_dying is non-zero, since if this happens after the cache has
been emptied, these pages will never be freed. This may cause "zombie
domains" to linger.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Currently a CPU is marked as present only after it has been kicked off
successfully, i.e. before the CPU is brought up, it is not
present. This patch try to mark CPU as present when it is detected
(either through MPS table or ACPI). If it can't be brought up
successfully, it will be marked as non-present again. This change is
mainly for CPU hot-plug. As discussed, we'd take two step for physical
CPU hot-add. A CPU is firstly marked as present, and later will bring
as online.
Also, In smp_boot_cpus(), xen need only scan all present CPU, and no
need to loop from 0... NR_CPUS. With this change, the bios_cpu_apicid
is not needed anymore.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
It also make some changes to current cpu online/offline logic:
1) Firstly, cpu online/offline will trigger a vIRQ to dom0 for status
changes notification.
2) It also add an interface to platform operation to online/offline
physical CPU. Currently the cpu online/offline interface is in sysctl,
which can't be triggered in kernel. With this change, it is possible
to trigger cpu online/offline in dom0 through sysfs interface.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
There are issues in updating the e820 map in the middle of a loop that
iterates over it. For example, after memmove(&e820.map[i],
&e820.map[i+1], ...), the original e820.map[i+1] become current
e820.map[i] but the next loop count is i+1, so the original
e820.map[i+1] will be skipped.
Fix and clarify the code by making a double loop.
Original bug discovery and fix by Xiao Guangrong <ericxiao.gr@gmail.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
In below case, e820_change_range_type() will return success:
[s, e] is in the middle of [rs, re] and e820->nr_map+1 >=
ARRAY_SIZE(e820->map) actually, it's failed, so this patch fix it
Signed-off-by: Xiao Guangrong <ericxiao.gr@gmail.com>
Blktap2 port of remus disk driver. Backwards compatable with blktap1
implementation.
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
Currently blktap2 opens a driver stack, closes it, and re-opens
it. This causes problems with our remus driver: the primary may
connect to the backup in between the first and second open.
This is a temporary fix.
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
Blktap2 allows block device drivers to be layered to create more
advanced virtual block devices. However, composing a layered driver is
not exposed to the user. This patch fixes this, and allows the user to
explicitly specify a driver chain when starting a tapdisk process,
using the pipe character ('|') to explicitly seperate layers in a
blktap2 configuration string.
for example, the command:
~$ tapdisk2 -n "log:|aio:/path/to/file.img"
will create a blktap2 device where read and write requests are passed
to the 'log' driver, then forwarded to the 'aio' driver.
Signed-off-by: Ryan O'Connor <rjo@cs.ubc.ca>
The tail containing the final PFN table, VCPU contexts and
shared_info_page is buffered, then the read loop is restarted.
After the first pass, incoming pages are buffered until the next tail
is read, completing a new consistent checkpoint. At this point, the
memory changes are applied and the loop begins again. When the fd read
fails, the tail buffer is processed.
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
This matches functionality in the tools already supporting the same
for DomU-s.
Code taken from Linux 2.6.32-rc and adjusted as little as possible to
be usable in Xen.
The question is whether, particularly for non-Linux Dom0-s, plain ELF
images compressed by bzip2 or lzma should also be supported.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
In addition to VBD read/write request#, add VBD read/write sector#
also. It makes VBD throughput observation easier. As the method to get
such info is OS dependent, just Linux version code is added.
Signed-off-by: Yang Xiaowei <xiaowei.yang@intel.com>
This patch fixes the recent regressions pointed out by Dexuan, keeping
pci passthrough working with stubdom too. In particular calling
device_create when pci_state == 'Initialising' is a mistake because
the state is always Initialising when attaching a device while
device_create has too be called only when the pci backend is missing.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Since Dom0 derives machine address ranges usable for assigning PCI
device resources from the output of this sub-hypercall, Xen should
make
sure it properly reports all ranges not suitable for this (as either
reserved or unusable):
- RAM regions excluded via command line option
- memory regions used by Xen itself (LAPIC, IOAPICs)
While the latter should generally already be excluded by the BIOS
provided E820 table, this apparently isn't always the case at least
for IOAPICs, and with Linux having got changed to account for this it
seems to make sense to also do so in Xen.
Generally the HPET range should also be excluded here, but since it
isn't being reflected in Dom0's iomem_caps (and can't be, as it's a
sub-page range) I wasn't sure whether adding explicit code for doing
so would be reasonable.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
1. Writing TMICT=0 disables the timer. Use this fact to simplify and
improve reprogram_timer(). In particular, we always write TMICT, and
write zero when we do not need a timer interrupt.
2. In HPET broadcast timer handler, set TMICT=0 when we mask the APIC
local timer. May as well do this early, before entering deep sleep.
3. In HVM-guest APIC emulation, disable the emulated local timer when
the guest sets TMICT=0. Previously we would issue an immediate
one-shot interrupt.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
- Use the device and inode information provided by losetup to find
if the vbd backing file is in use on another vbd.
- Use losetup to find a free loopback device.
Signed-off-by: Gary Grebus <gary.grebus@oracle.com>
Avoid races between hotplug "add" and "remove" leading to "leaked"
loopback devices.
- Don't setup loopback device if xend is no longer waiting for the
vbd.
- Use the lock file to avoid add/remove races.
Signed-off-by: Gary Grebus <gary.grebus@oracle.com>
- Clean initialisation of new vcpu_info in map_vcpu_info() if the
vcpu was previously using the shared dummy structure.
- Don't allow a vcpu to run with teh shared dummy info structure, as
no good can come of it.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
- Originally the max vcpu number for HVM guest is 32, this patch
extend the number to 128 on x86_64 hypervisor. (For i386 hypervisor,
the max vcpu number is still 32).
- This patch extends the mp-table size to fit more vcpus.
- HVM PV driver should call VCPUOP_register_vcpu_info hypercall to
initialize the vcpu info if the vcpu number is more than 32.
Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The built-in bash command wait should be able to take a pid argument
and just wait for the specified process to die, but it currently has a
bug and what actually does is waiting for the death of all the
children. For this reason the stubdom-dm script doesn't exit properly
after stubdom destruction. This patch solves the issue spawning only
one child, removing the sleep subprocess workaround that was used to
create a usable stdin for "xm console" and replacing it with a fifo.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reduce size of Xen-qemu shared ioreq structure to 32 bytes. This
has two advantages:
1. We can support up to 128 VCPUs with a single shared page
2. If/when we want to go beyond 128 VCPUs, a whole number of ioreq_t
structures will pack into a single shared page, so a multi-page
array will have no ioreq_t straddling a page boundary
Also, while modifying qemu, replace a 32-entry vcpu-indexed array
with a dynamically-allocated array.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
- xmalloc currently faults if xmalloc_new_page fails due to OOM
- realloc treats xmalloc_hdr.size as the size of just the data region
rather than the total size of data region + headers + padding.
From: James Pendergrass <James.Pendergrass@jhuapl.edu>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Keir Fraser