This currently relies on the third-party IMQ patch (linuximq.net)
being present in dom0. The plan is to replace this with a direct hook
into netback eventually.
This patch includes a pared-down and patched copy of ebtables to
install IMQ on a VIF.
Signed-off-by: Brendan Cully <brendan@cs.ubc.ca>
This patch implements pci passthrough (hotplug and coldplug) in
libxenlight, it also adds three new commands to xl: pci-attach,
pci-detach and pci-list.
Currently flr on a device is done writing to
/sys/bus/pci/drivers/pciback/do_flr
pciback do_flr is present in both XCI and XCP 2.6.27 kernels.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This patch makes sure that the domain name to domid conversion is
correct, cross referencing the information found on xenstore with the
list of running domains.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
This is safe, as described in a code comment. Also fix up another
comment in start_secondary() while we're there.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
When cpu hot-added, this assumption is broken because the hot-added
CPU may be brougt online by dom0 in arbitrary order. This patch avoids
making this assumption while still linking vcpus in ascending order of
identifier.
Signed-off-by: Jiang, Yunhong <yunhong.jiang@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
The old implementation of alloc_idle_vcpu() is unnecessary since
arch-specific code ensures that a single idle domain supports NR_CPUS
vcpus, despite the usual limit of MAX_VIRT_CPUS for ordinary domains.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
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>
Keir Fraser