The reservation of space for the kexec area in
kexec_reserve_area is incorrect. It specifies the
start address and size to reserve_e820_mem when
the args should be start and end.
Bug found and fixed by Dave Anderson.
Signed-off-by: Bill Burns <bburns@redhat.com>
Handle 64bit operations in stdvga instead of throwing away the
upper 32bits.
This fixes some noisy xen messages like "invalid io size: 8".
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Sampling and collecting dynamic Px statistic data, including
Px state value, Px count, Px residency time, Px transition
matrix, etc. Provide Px statistic data to user through libxc.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
This patch fixes several bugs in serial.c
(1) A typo in serial_save() where qemu_get_8s is called (should be
qemu_put_8s)
(2) No support provided in serial_load() for version_id == 1 (should
unmarshal a 1 byte s->divider and should provide a default value
for s->fcr)
(3) Call serial_ioport_write() to initialize s->fcr. It is not
sufficient to load its value; other hidden values (such as
s->recv_fifo.itl) must be re-initialized.
Signed-off-by: Ben Guthro <bguthro@virtualiron.com>
Signed-off-by: Robert Phillips <rphillips@virtualiron.com>
The device configurations of suspended virtual machines are
inaccessible even though for example the UUIDs of the VIFs and VBDs
are known and returned when VM.get_VIFs()/get_VBDs() is called, though
when trying to access their records for example, then handle is
reported as being invalid. This patch fixes this.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
According to ACPI spec., x_firmware_waking_vector in FACS is for
waking up in protected mode and firmware_waking_vector is for in real
mode. Xen once use x_firmware_waking_vector which can make S3 failed
on some platform. This patch fixed the bug by using non-x one.
Signed-off-by: Huacai Chen <huacai.chen@intel.com>
The recent fix to validate the frontend's frame buffer description
neglected to limit the frame buffer size correctly. This lets a
malicious frontend make the backend attempt to map an arbitrary amount
of guest memory, which could be useful for a denial of service attack
against dom0.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
The code for working out the base address of a 64-bit BAR currently
puts the two halves together in the wrong order and leaves the type
bits in the resulting value. It also treats
PCI_BASE_ADDRESS_MEM_TYPE_64 as a flag rather than an enumeration
value.
Signed-off-by: Neil Turton <nturton@solarflare.com>
Based on initialized cpufreq infrustructure, setup a timer on
each PSD domain, periodicly sample cpu load and driver cpu to
some Px state according to cpu load and cpu coordination.
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Initializing basic Px data structure, setup cpufreq infrastructure:
* cpufreq data structure initializing, including freq table and policy;
* basic driver and tools, to measure freq or drive to Px target;
* setup _PSD domain to coordinately work;
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
Add platform op hypercall case to get ACPI Px info from dom0.
Chose Px controller from dom0 (cpufreq=dom0-kernel)
or hypervisor (cpufreq=xen).
Signed-off-by: Liu Jinsong <jinsong.liu@intel.com>
A domain fails to restore on IA64 since cset 17524:18727843db60.
This patch fixes it temporarily. Guest CPUID configuration for IA64
might be implemented in the future.
Signed-off-by: Kouya Shimura <kouya@jp.fujitsu.com>
The protocol field of the blkif interface is correct at startup for a
guest of a different mode from dom0 (eg. 32-bit dom0, 64-bit guest).
However, this property is not persisted on save, so a later restore
(or migrate) will setup the block interface with the wrong mode.
Signed-off-by: Herbert van den Bergh <herbert.van.den.bergh@oracle.com>
Signed-off-by: Kurt Hackel <kurt.hackel@oracle.com>
This patch is related to Changeset 15635:7bdc9f6407d3
<http://xenbits.xensource.com/staging/xen-unstable.hg?rev/7bdc9f6407d3>
[PVFB] Fix shift key for graphical vnc display.
With above patch, if a user presses shift-insert, qemu sends shift
down, shift up, insert down and then another shift key down (see trace
below). This makes it impossible to do shift insert pasting or use
guest hot shifted-Fkeys.
Shift Insert trace:
do_key_event():1135 keycode:2a shift down
kbd_put_keycode():539 keycode:2a send shift down
do_key_event():1135 keycode:d2 insert down
kbd_put_keycode():539 keycode:aa send shift up
kbd_put_keycode():539 keycode:e0 send insert down
kbd_put_keycode():539 keycode:52
do_key_event():1135 keycode:d2 insert up
kbd_put_keycode():539 keycode:e0 send insert up
kbd_put_keycode():539 keycode:d2
kbd_put_keycode():539 keycode:2a send shift down
do_key_event():1135 keycode:2a shift up
kbd_put_keycode():539 keycode:aa send shift up
This patch adds a check for the keycode being shiftable, something
other than a keypad key, f1-12 , insert, del , etc. before allowing
the press_shift_up() operation.
Signed-off-by: Pat Campbell <plc@novell.com>
Patch sends a UNIT_ATTENTION(6), MEDIUM_MAY_HAVE_CHANGED(0x28) sense
when cdrom transitions from not ready to ready.
ATA Packet interface for CD-ROMS, SFF8020i.pdf. See state diagram
Figure 12, page 82 and Table 44 -recommended Sense Key, ASC
With patch in place HVM win2008 server guest sees the CD/DVD contents
have changed when the media is switched.
Signed-off-by: Pat Campbell <plc@novell.com>
Patch puts 0xe0 prefix before putting right alt or right cntrl
keycodes. Also adds keysm definition for ISO_Left_Tab.
Signed-off-by: Pat Campbell <plc@novell.com>
A buggy or malicious frontend can describe its shared framebuffer to
the backend in a way that makes the backend map an arbitrary amount of
guest memory, malloc an arbitrarily large internal buffer, copy
arbitrary memory to that buffer, even beyond its end. A domU running
a malicious frontend can abuse the former two for denial of service
attacks against dom0. It can abuse the third to write arbitrary
backend memory. It can abuse all three to terminate or crash the
backend. Arbitrary code execution looks quite feasible.
In more detail (ignoring #ifdef CONFIG_STUBDOM code):
The frame buffer is described by the following parameters:
* fb_len (size of shared framebuffer)
* width, height, depth
* row_stride, offset
fb_len is fixed on startup. The frontend can modify the other
parameters by sending a XENFB_TYPE_RESIZE event.
xenfb_read_frontend_fb_config() limits fb_len according to backend
configuration parameter videoram (from xenstore), if present. I
believe videoram is not present by default.
xenfb_map_fb() uses fb_len to map the frontend's framebuffer.
The frontend can make it map arbitrarily much, unless limited by the
videoram configuration parameter. This flaw always existed.
xenfb_register_console() and xenfb_on_fb_event() pass width, height,
depth and rowstride to QEMU's DisplayState object. The object sets
itself up to work directly on the framebuffer (shared_buf true) if
parameters allow that. Else it allocates an internal buffer of size
height * width * depth / 8 (shared_buf false).
The frontend can make it allocate arbitrarily much. This flaw always
existed.
xenfb_register_console() and xenfb_on_fb_event() pass width, height,
depth and rowstride to QEMU's DisplayState object. The object sets
itself up to work directly on the framebuffer (shared_buf true) if
parameters allow that. Else it allocates an internal buffer of size
height * width * depth / 8 (shared_buf false).
The frontend can make it allocate arbitrarily much. This flaw was
introduced by the move of PVFB into QEMU (xen-unstable cset 16220
ff).
xenfb_on_fb_event() uses width and height to clip the area of an
update event. It then passes that area to xenfb_guest_copy().
xenfb_invalidate() passes the complete screen area to
xenfb_guest_copy(). xenfb_guest_copy() copies the argument area (x,
y, w, h) into the internal buffer, unless shared_buf is true. This
copies h blocks of memory. The i-th copy (counting from zero) copies
w * depth / 8 bytes
from
shared framebuffer + offset + (y + i) * row_stride + x * depth / 8
to
internal buffer + (y + i) * ds->linesize + x * ds->depth / 8
where ds->linesize and ds->depth are parameters of the internal buffer
chosen by the backend.
This copy can be made to read from the shared framebuffer and write to
the internal buffer out of bounds. I believe the frontend can abuse
this to write arbitrary backend memory.
The flaw in its current form was introduced by the move of PVFB into
QEMU (xen-unstable cset 16220 ff). Before, the framebuffer was always
shared.
From: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
actually be switched to 0, we must check VMX_BASIC_MSR[55] and
possibly check a set of 'true' feature MSRs.
Signed-off-by: Jun Nakajima <jun.nakajima@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
This is because function "uname = config.get('uname', '')" returns '',
rather than None, if uname is not in config variable.
Signed-off-by: Xu Dongxiao <dongxiao.xu@intel.com>
If we define wrong values to a disk parameter in domain configuration
files, we get an error message or a guest OS panic.
1. If we define a wrong disk type, xm create command error occurs
about 100 seconds later.
e.g. disk=['xyz:/xen/root-vm1.img,hda1,w']
2. If we forget a disk type, a guest OS panic occurs.
e.g. disk=['/xen/root-vm1.img,hda1,w']
Signed-off-by: Masaki Kanno <kanno.masaki@jp.fujitsu.com>
Printing page_to_maddr() and page_to_mfn() of the same page is
redundant, and _p(page_to_maddr(page)) is even incorrect on x86/PAE.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
* make the xenstore reader in qemu-dm's startup determine which
of qemu's block drivers to use according to the xenstore
backend `type' field. This `type' field typically comes from
the front of the drive mapping string in ioemu. The
supported cases are:
xm config file string `type' image format qemu driver
phy:[/dev/]<device> phy raw image bdrv_raw
file:<filename> file raw image bdrv_raw
tap:aio:<filename> tap raw image bdrv_raw
tap:qcow:<image> tap not raw autoprobe
tap:<cow-fmt>:<image> tap named format bdrv_<cow-fmt>
It is still necessary to autoprobe when the image is specified as
`tap:qcow:<image>', because qemu distinguishes `qcow' and `qcow2'
whereas blktap doesn't; `qcow' in xenstore typically means what
qemu calls qcow2. This is OK because qemu can safely distinguish
the different cow formats provided we know it's not a raw image.
* Make the format autoprobing machinery never return `raw'. This has
two purposes: firstly, it arranges that the `tap:qcow:...' case
above can be handled without accidentally falling back to raw
format. Secondly it prevents accidents in case the code changes in
future: autoprobing will now always fail on supposed cow files which
actually contain junk, rather than giving the guest access to the
underlying file.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser