Currently the callers of vscsi_get_scsidevices() do not pass a mask
string. This will call "lsscsi -g '[]'", which causes a lsscsi syntax
error. As a result the sysfs parser _vscsi_get_scsidevices() is used.
But this parser is broken and the specified names in the config file are
not found.
Using a mask '*' if no mask was given will call lsscsi correctly and the
following config is parsed correctly:
vscsi=[
'/dev/sg3, 0:0:0:0',
'/dev/disk/by-id/wwn-0x600508b4000cf1c30000800000410000, 0:0:0:1'
]
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26009:2dbfa4d2e107
Backport-requested-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Currently pvscsi can not pass SCSI devices that have just a scsi_generic node.
In the following example sg3 is a control LUN for the disk sdd.
But vscsi=['4:0:2:0,0:0:0:0'] does not work because the internal 'devname'
variable remains None. Later writing p-devname to xenstore fails because None
is not a valid string variable.
Since devname is used for just informational purpose use sg also as devname.
carron:~ $ lsscsi -g
[0:0:0:0] disk ATA FK0032CAAZP HPF2 /dev/sda /dev/sg0
[4:0:0:0] disk HP P2000G3 FC/iSCSI T100 /dev/sdb /dev/sg1
[4:0:1:0] disk HP P2000G3 FC/iSCSI T100 /dev/sdc /dev/sg2
[4:0:2:0] storage HP HSV400 0950 - /dev/sg3
[4:0:2:1] disk HP HSV400 0950 /dev/sdd /dev/sg4
[4:0:3:0] storage HP HSV400 0950 - /dev/sg5
[4:0:3:1] disk HP HSV400 0950 /dev/sde /dev/sg6
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26008:eecb528583d7
Backport-requested-by: Olaf Hering <olaf@aepfle.de>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
25886:051e2a30e3fb (25894:95a971c8058f in xen-unstable) is wrong
because it assumes that xc_sharing_freed_pages etc. return -errnoval
on error. However, like other libxc calls they return -1 setting
errno.
Correct this, checking for l<0 and then testing errno against ENOSYS,
and also log the correct errno value.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
These fields need to be valid at all times. Hypervisor ensures this
even across 32/64-bit guest transitions.
This fixes a bug where wallclock time is incorrect for booting 32-bit
HVM guests.
This should be backported to Xen 4.1 and 4.2.
Signed-off-by: Keir Fraser <keir@xen.org>
Tested-and-Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
xen-unstable changeset: 25908:12fa949b9060
xen-unstable date: Fri Sep 14 18:47:57 UTC 2012
libutil.h is only needed on BSDs, but not in Linux. Debian package
libbsd-dev-0.3.0-1 installed a libutil.h overlay that contains a
Perform the libutil.h check with -Werror, so we don't include this
bogus header.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26005:cdb48f1742f3
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
CentOS 5.x forked e2fs ext4 support into a different package called
e4fs, and so headers and library names changed from ext2fs to ext4fs.
Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
ext2fs to build libfsimage. This patch assumes that if the ext4fs
library is present it should always be used instead of ext2fs.
This patch includes a rework of the ext2fs check, a new ext4fs check
and a minor modification in libfsimage to use the correct library.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25895:98e1ba6a672a
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
In commit e8d40584, it intended to check xml file size and when empty will
return, the condition should be "if os.path.getsize(xml_path) == 0" rather
then "if not os.path.getsize(xml_path) == 0".
Signed-off-by: Chuang Cao <chuang.cao@oracle.com>
Signed-off-by: Joe Jin <joe.jin@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26088:dd64a1bdbe3a
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
There are two egcs in an ao initiator: the one in the AO_CREATE
function, and the one in libxl__ao_inprogress. If synchronous ao
operation generates progress events and completes immediately, the
progress callbacks end up queued in the outer egc. These callbacks
are currently only called after libxl__ao_inprogress has returned, and
keep the ao alive until they happen. This is not good because the
principle is that a synchronous ao is not supposed to survive beyond
libxl__ao_inprogress's return.
The fix is to ensure that the callbacks queued in the outer egc are
called early enough that they don't preserve the ao. This is
straightforward in the AO_INPROGRESS macro because AO_CREATE's egc is
not used inside that macro other than to destroy it. All we have to
do is destroy it a bit sooner.
This involves unlocking and relocking the ctx since EGC_FREE expects
to be called with the lock released but libxl__ao_inprogress needs it
locked. This hole in our lock tenure is fine - libxl__ao_inprogress
has such holes already.
It is still possible to use the CTX_LOCK macros for this unlock/lock
because the gc we are using is destroyed only afterwards by
libxl__ao_inprogress.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26080:25b2f53d2583
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Make xl/libxl accept the long option --wait for -w to be compatible with xm.
The long options are used in the default init and sysconfig scripts.
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26045:ba7198bfc679
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Options for the shutdown command that are supplied behind the domain id are
ignored. In case of the default xendomains init script this means that it will
not wait for the domains to be actually shutdown.
Signed-off-by: Sander Eikelenboom <linux@eikelenboom.it>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26044:4845b5ce90e8
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
In the toplevel Makefile "install-docs" (depended on by "install" and
hence "dist"), but not "build", ignores errors.
This was inherited from before 24563:4271634e4c86, prior to which the
||true seems intended to handle failures of check_pkgs. Nowadays we
handle docs tools individually in the docs makefiles so there is no
need for this ||true here.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26042:3696dd6a7836
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
If pygrub was called with --args="some thing", then this string should
be append to the kernel command line. But the last changeset
25941:795c493fe561 contained a typo, it assigns 'args' instead of 'arg'.
Rename the local variable which holds the string from the domain config
file to avoid further confusion.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26018:ecc7627ca6d7
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Recently I changed my rpm xen.spec file from doing
'make -C tools -j N && make stubdom' to 'make -j N stubdom' because
stubdom depends on tools, so both get built.
The result was the failure below.
....
mkdir -p grub-x86_64
CPPFLAGS="-isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include -D__MINIOS__ -DHAVE_LIBC -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../tools/xenstore -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86 -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/x86/x86_64 -U __linux__ -U __FreeBSD__ -U __sun__ -nostdinc -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os/include/posix -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/cross-root-x86_64/x86_64-xen-elf/include -isystem /usr/lib64/gcc/x86_64-suse-linux/4.7/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include -isystem /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/lwip-x86_64/src/include/ipv4 -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/include -I/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../xen/include" CFLAGS="-mno-red-zone -O1 -fno-omit-frame-pointer -m64 -mno-red-zone -fno-reorder-blocks -fno-asynchronous-unwind-tables -m64 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement -Wno-unused-but-set-variable -fno-stack-protector -fno-exceptions" make DESTDIR= -C grub OBJ_DIR=/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub-x86_64
make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
make[2]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
make[2]: *** INTERNAL: readdir: Bad file descriptor
. Stop.
make[2]: Makefile: Field 'stem' not cached: Makefile
make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/grub'
make[1]: *** [grub] Error 2
[ -d mini-os-x86_64-xenstore ] || \
for i in $(cd /home/abuild/rpmbuild/BUILD/xen-4.2.25602/non-dbg/stubdom/../extras/mini-os ; find . -type d) ; do \
mkdir -p mini-os-x86_64-xenstore/$i ; \
done
....
Expanding every occurrence of CROSS_MAKE avoids this error. It also has
the nice side effect of actually enabling parallel build for stubdom.
According to the GNU make documentation $(MAKE) gets its special meaning
only if it appears directly in the recipe:
http://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26011:b6fb4e63b946
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Remove 4 from default runlevel in xenballoond.init.
Similar to what changeset 24847:0900b1c905f1 does in xencommons, remove
runlevel 4 from the other runlevel scripts. LSB defines runlevel 4 as
reserved for local use, the local sysadmin is responsible for symlink
creation in rc4.d.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 26007:fe756682cc7f
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Previously device ids in libxl were treated as integers meaning they
were being initialized to 0, which is a valid device id. This patch
makes devid its own type in libxl and initializes it to -1, an invalid
value.
This fixes a bug where if you try to do a xl DEV-attach multiple
time it will continuously try to reattach device 0 instead of
generating a new device id.
Signed-off-by: Matthew Fioravante <matthew.fioravante@jhuapl.edu>
Reviewed-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25988:8a073eb1e849
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
If a bootloader entry in menu.lst has no additional kernel command line
options listed and the domU.cfg has 'bootargs="--args=something"' the
additional arguments from the config file are not passed to the kernel.
The reason for that incorrect behaviour is that run_grub appends arg
only if the parsed config file has arguments listed.
Fix this by appending args from image section and the config file separatly.
To avoid adding to a NoneType initialize grubcfg['args'] to an empty string.
This does not change behaviour but simplifies the code which appends the
string.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25941:795c493fe561
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Without this, the api check cpp run might happen before the various
autogenerated files which are #include by libxl.h are ready.
We need to remove the api-ok file from AUTOINCS to avoid a circular
dependency. Instead, we list it explicitly as a dependency of the
object files. The result is that the api check is the last thing to
be done before make considers the preparation done and can start work
on compiling .c files into .o's.
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25901:c51229d1522e
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Currently, xentop calls clear() before drawing the screen and calling
refresh(). This causes the entire screen to be repainted from scratch
on each call to refresh(). It is inefficient and causes visible flicker
when using xentop.
This patch fixes this by calling erase() instead of clear() which overwrites
the current screen with blanks instead. The screen is then drawn as usual
in the top() function and refresh() is called. This method allows curses
to only repaint the characters that have changed since the last call
to refresh(), thus avoiding the flicker and sending fewer characters to
the terminal.
In the event the screen becomes corrupted, this patch accepts a CTRL-L
keystroke from the user which will call clear() and force a repaint of
the entire screen.
Signed-off-by: Jason McCarver <slam@parasite.cc>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25899:116f5c34354b
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Print an error and exit if backend!=0 is used in conjunction with
run_hotplug_scripts. Currently libxl can only execute hotplug scripts
from the toolstack domain (the same domain xl is running from).
Added a description and workaround of this issue on
xl-network-configuration.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25897:ff6d94944039
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
vif interfaces allows the user to specify the domain that should run
the backend (also known as driver domain) using the 'backend'
parameter. This is not compatible with run_hotplug_scripts=1, since
libxl can only run the hotplug scripts from the Domain 0.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25896:259c4e9d8adf
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
On a 32 bit hypervisor xl info currently reports:
sharing_freed_memory : 72057594037927935
sharing_used_memory : 72057594037927935
Eat the ENOSYS and turn it into 0. Log and propagate other errors.
I don't have a 32 bit system handy, so tested on x86_64 with a libxc
hacked to return -ENOSYS and -EINVAL.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Andres Lagar-Cavilla <andres@lagarcavilla.org>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25894:95a971c8058f
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This patch corrects the following errors produced by pod2man:
Hey! The above document had some coding errors, which are explained
below:
Around line 301:
You can't have =items (as at line 305) unless the first thing after
the =over is an =item
Around line 311:
'=item' outside of any '=over'
Signed-off-by: Matt Wilson <msw@amazon.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25840:c7e4b7e64303
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
device_backend_callback error path always says "unable to disconnect",
but this can also happen during the connection of a device. Fix the
error message using the information in aodev->action.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
xen-unstable changeset: 25838:2f418851f36d
Backport-requested-by: Ian Campbell <Ian.Campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Allowing user supplied kernels of arbitrary sizes, especially during
decompression, can swallow up dom0 memory leading to either virtual
address space exhaustion in the builder process or allocation
failures/OOM killing of both toolstack and unrelated processes.
We disable these checks when building in a stub domain for pvgrub
since this uses the guest's own memory and is isolated.
Decompression of gzip compressed kernels and ramdisks has been safe
since 14954:58205257517d (Xen 3.1.0 onwards).
This is XSA-25 / CVE-2012-4544.
Also make explicit checks for buffer overflows in various
decompression routines. These were already ruled out due to other
properties of the code but check them as a belt-and-braces measure.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
It has always been puzzling me why the first IO-APIC gets special cased
in two places, and finally Xen got run on a system where this breaks:
(XEN) ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 16, version 17, address 0xfecff000, GSI 0-2
(XEN) ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
(XEN) IOAPIC[1]: apic_id 15, version 17, address 0xfec00000, GSI 3-38
(XEN) ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
(XEN) IOAPIC[2]: apic_id 14, version 17, address 0xfec01000, GSI 39-74
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl)
i.e. all legacy IRQs (apart from the timer one, but the firmware passed
data doesn't look right for that case anyway, as both Xen and native
Linux are falling back to use the virtual wire setup for IRQ0,
apparently rather using pin 2 of the first IO-APIC) are being handled
by the second IO-APIC.
This at once eliminates the possibility of an unmasked RTE getting
written without having got a vector put in place (in
setup_IO_APIC_irqs()).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 26102:22e08c9ac770
xen-unstable date: Wed Oct 24 15:51:48 UTC 2012
Which was failing with this:
viridian.c: In function ‘wrmsr_viridian_regs’:
viridian.c:254:1: error: ‘PERFC_mshv_wrmsr_apic_msr’ undeclared
(first use in this function)
viridian.c:254:1: note: each undeclared identifier is reported only
once for each function it appears in
viridian.c: In function ‘rdmsr_viridian_regs’:
viridian.c:305:1: error: ‘PERFC_mshv_rdmsr_apic_msr’ undeclared
(first use in this function)
as a consequence of 17b754cab7b0 using but not defining
the counters.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 26098:6d54c3338c52
xen-unstable date: Tue Oct 23 11:12:22 UTC 2012
Values in regs can be newer than those in the shadow vmcb (e.g. due to
an instruction emulation right before). So use the values from regs.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 26096:d642720e1ea9
xen-unstable date: Tue Oct 23 07:14:27 UTC 2012
Committed-by: Jan Beulich <jbeulich@suse.com>
Fix memory leak of l1 vmcb page when destroying a vcpu while l2 guest
is running.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 26095:a7503ce27d46
xen-unstable date: Tue Oct 23 07:13:27 UTC 2012
Committed-by: Jan Beulich <jbeulich@suse.com>
During kexec in a ballooned PVonHVM guest the new kernel needs to check
each pfn if its backed by a mfn to find ballooned pages. Currently all
PoD and grant pages will appear as HVMMEM_mmio_dm, so the new kernel has
to assume they are ballooned. This is wrong: PoD pages may turn into
real RAM at runtime, grant pages are also RAM.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 26093:4ae08ca5500f
xen-unstable date: Fri Oct 19 16:09:05 2012 +0200
The IRQ descriptor lock should be held while adjusting the affinity of
any IRQ; the HPET channel lock isn't sufficient to protect namely
against races with moving the IRQ to a different CPU.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 26063:1f4be6ee4619
xen-unstable date: Wed Oct 17 12:13:20 UTC 2012
Rather than per-cpu filtering for every page in a super-page
allocation, simply remember the most recent TLB timestamp across all
allocated pages, and filter on that, just once, at the end of the
function.
For large-CPU systems, doing 2MB allocations during domain creation,
this cuts down the domain creation time *massively*.
TODO: It may make sense to move the filtering out into some callers,
such as memory.c:populate_physmap() and
memory.c:increase_reservation(), so that the filtering can be moved
outside their loops, too.
Signed-off-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 26056:177fdda0be56
xen-unstable date: Mon Oct 15 15:38:11 UTC 2012
While trying oprofile under Xen, I noticed that HVM passive domain's
kernel addresses were showing up as user application. It turns out
under HVM get_cpu_user_regs()->cs contains 0x0000beef.
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Don't cast away const-ness. Use SS instead of CS to determine ring.
Special-case real and protected mode.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 26055:14e32621dbaf
xen-unstable date: Mon Oct 15 13:04:51 UTC 2012
[ 0.020294] ------------[ cut here ]------------
[ 0.020311] WARNING: at arch/x86/xen/enlighten.c:730
xen_apic_write+0x15/0x17()
[ 0.020318] Hardware name: empty
[ 0.020323] Modules linked in:
[ 0.020334] Pid: 1, comm: swapper/0 Not tainted 3.3.8 #7
[ 0.020340] Call Trace:
[ 0.020354] [<ffffffff81050379>] warn_slowpath_common+0x80/0x98
[ 0.020369] [<ffffffff810503a6>] warn_slowpath_null+0x15/0x17
[ 0.020378] [<ffffffff810034df>] xen_apic_write+0x15/0x17
[ 0.020392] [<ffffffff8101cb2b>] perf_events_lapic_init+0x2e/0x30
[ 0.020410] [<ffffffff81ee4dd0>] init_hw_perf_events+0x250/0x407
[ 0.020419] [<ffffffff81ee4b80>] ? check_bugs+0x2d/0x2d
[ 0.020430] [<ffffffff81002181>] do_one_initcall+0x7a/0x131
[ 0.020444] [<ffffffff81edbbf9>] kernel_init+0x91/0x15d
[ 0.020456] [<ffffffff817caaa4>] kernel_thread_helper+0x4/0x10
[ 0.020471] [<ffffffff817c347c>] ? retint_restore_args+0x5/0x6
[ 0.020481] [<ffffffff817caaa0>] ? gs_change+0x13/0x13
[ 0.020500] ---[ end trace a7919e7f17c0a725 ]---
Kernel function check_hw_exists() writes 0xabcd to msr 0xc0010201 (Performance Event
Counter 0) and read it again to check if it is running as dom0. Early amd cpus does
not reset perf counters during warm reboot. If the kernel is booted with bare metal
and then as a dom0, the content of msr 0xc0010201 will stay and the checking will
pass and PMU will be enabled unexpectedly.
Signed-off-by: Wei Wang <wei.wang2@amd.com>
Don't reset the counters when used for the NMI watchdog.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 26054:983108e1b56b
xen-unstable date: Mon Oct 15 13:03:36 UTC 2012
This allows Xen to walk the l1 hypervisor's shadow pagetable
correctly. Not needed for hap-on-hap guests because they are handled
at lookup time. Problem found with 64bit Win7 and 32bit XPMode where Win7
switches forth and back between long mode and PAE legacy pagetables.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
[Adjusted to update in all cases where the l1 vmm uses shadows]
Signed-off-by: Tim Deegan <tim@xen.org>
xen-unstable changeset: 25984:a9c84069c248
xen-unstable date: Thu Oct 4 13:20:50 UTC 2012
Checking the stored version doesn't tell us anything about the need to
apply the update (during resume, what is stored doesn't necessarily
match what is loaded).
Note that the check can be removed altogether because once switched to
use what was read from the CPU (uci->cpu_sig.rev, as used in the
subsequent pr_debug()), it would become redundant with the checks that
lead to microcode_update_match() returning the indication that an
update should be applied.
Note further that this was not an issue on APs since they start with
uci->mc.mc_intel being NULL.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Tested-by: Ben Guthro <ben@guthro.net>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25965:4496d56c68a0
xen-unstable date: Fri Sep 28 07:28:11 UTC 2012
There are two greater-than-zero checks for the old vector retrieved,
which don't work when a negative value got stashed into the respective
arch_irq_desc field. The effect of this was that for interrupts that
are intended to get their affinity adjusted the first time before the
first interrupt occurs, the affinity change would fail, because the
original vector assignment would have caused the move_in_progress flag
to get set (which causes subsequent re-assignments to fail until it
gets cleared, which only happens from the ->ack() actor, i.e. when an
interrupt actually occurred).
This addresses a problem introduced in c/s 23816:7f357e1ef60a (by
changing IRQ_VECTOR_UNASSIGNED from 0 to -1).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25962:41f523f1b5e5
xen-unstable date: Fri Sep 28 07:23:34 UTC 2012
We shouldn't clear HPET_TN_FSB right after we (indirectly, via
request_irq()) enabled it for the channels we intend to use for
broadcasts.
This fixes a regression introduced by c/s 25103:0b0e42dc4f0a.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25961:6a5812129094
xen-unstable date: Fri Sep 28 07:22:14 UTC 2012
When a domain is mapping pages from a different pg_owner domain, the
iomem_access checks are currently only applied to the pg_owner domain,
potentially allowing a domain with a more restrictive iomem_access
policy to have the pages mapped into its page tables. To catch this,
also check the owner of the page tables. The current domain does not
need to be checked because the ability to manipulate a domain's page
tables implies full access to the target domain, so checking that
domain's permission is sufficient.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset: 25952:8278d7d8fa48
xen-unstable date: Wed Sep 26 09:56:07 UTC 2012
Secondary CPUs, between doing their final memory writes (particularly
updating cpu_initialized) and getting a subsequent INIT, may not write
back all modified data. The INIT itself then causes those modifications
to be lost, so in the cpu_initialized case the CPU would find itself
already initialized, (intentionally) entering an infinite loop instead
of actually coming online.
Signed-off-by: Ben Guthro <ben@guthro.net>
Make acpi_dead_idle() call default_dead_idle() rather than duplicating
the logic there.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25940:c8d65d91a6f2
xen-unstable date: Tue Sep 25 06:38:14 UTC 2012
Properly checking the MFN implies knowing the physical address width
supported by the platform, so to obtain this consistently the
respective code gets moved out of the MTRR subdir.
Btw., the model specific workaround in that code is likely unnecessary
- I believe those CPU models don't support 64-bit mode. But I wasn't
able to formally verify this, so I preferred to retain that code for
now.
But domctl code here also was lacking other error checks (as was,
looking at it again from that angle) the XEN_DOMCTL_ioport_mapping one.
Besides adding the missing checks, printing is also added for the case
where revoking access permissions didn't work (as that may have
implications for the host operator, e.g. wanting to not pass through
affected devices to another guest until the one previously using them
did actually die).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25931:149805919569
xen-unstable date: Thu Sep 20 07:21:53 UTC 2012
In particular, the case of "np" being a very large value wasn't handled
correctly. The range start checks also were off by one (except that in
practice, when "np" is properly range checked, this would still have
been caught by the range end checks).
Also, is a GFN wrap in XEN_DOMCTL_memory_mapping really okay?
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
xen-unstable changeset: 25927:3e3959413b2f
xen-unstable date: Wed Sep 19 07:27:55 UTC 2012