George Dunlap reports that gcc 4.4.3 complains:
libxl_dm.c: In function libxl__create_device_mode:
libxl_dm.c:776: error: format not a string literal and no format arguments
And indeed the format argument here is a char * from libxl__domain_bios().
Make the argument to libxl__xs_write a const char * and change
libxl__domain_bios to return a const char too.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
It prevents callers from deliberately passing file descriptors to the child,
hides any callers who erroneously do so and doesn't deal with all file
descriptors in any case.
Rather than remove it all together replace it with some debug code
which checks for open file handles which do not have either O_CLOEXEC
or FD_CLOEXEC set. To enable the debug set _LIBXL_DEBUG_EXEC_FDS=1 to
print any open and non-CLOEXEC non-stdio FDs just before libxl__exec
actualy calls exec. Set _LIBXL_DEBUG_EXEC_FDS=2 to abort if any of
these exist.
On the basis of this debugging fix some leaked filehandles:
* The read end of the pipe used to wake the parent from the
intermediate process during libxl__spawn_spawn was leaked into the
intermediate process.
* The file descriptor representing the xl lock was not marked
O_CLOEXEC (the lock itself is already specified to not be
inherited across a fork).
* The file descriptors passed to libxl__exec to be dup'd as
std{in,out,err} were leaked at their original number. They are
harmless (an attacker can just as easily use fd 0..2) but close
anyway since it removes a case which a person evaluating open fd's
needs to consider.
* libxl_run_bootloader was leaking the xenconsole pty master into
the bootloader child process.
* If the bootloader fails to get as far as opening its end of the
FIFO then we can also hang, check that the process has not exited
as part of that loop. (we actually block opening the FIFO too so
this is only a partial fix for the case where the bootlader has
crashed quickly).
With these fixes I have tested that device models, bootloaders
(pygrub) and vncviewers which are spawned via libxl__exec with no
unexpected file descriptors open, at least in my configuration.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Distinguish between device model dying during startup (libxl__spawn_check
returns failure) and timing out while waiting for the xenstore node to show up.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Parsing /otc/source/vtd/xen-unstable/tools/python/../../tools/libxl/libxl.idl
File "/usr/lib64/python2.4/site-packages/xen/remus/save.py", line 169
finally:
^
SyntaxError: invalid syntax
This was introduced in 23195:13ec53a59a42
It is a problem for Python 2.4 and earlier, only.
So use try...(try...except)...finally as suggested by Ian Campbell.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Acked-by: Shriram Rajagopalan <rshriram@cs.ubc.ca>
Acked-by: Ian Campbell <Ian.Campbell@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
When the device model is starting up push checks for spawn failure down into
libxl__wait_for_device_model, allowing us to fail more quickly when the device
model fails to start (e.g. due to a missing library or an early setup error
etc).
In order to allow the select loop in libxl__wait_for_device_model to wake when
the child dies add pipe between the parent and the intermediate process which
the intermediate process can use to signal the parent.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Passing a libxl__device_model_starting to a generic function and expecting it
to scrobble inside for the generic data structure is a strange interface.
Instead pass in a libxl__spawn_starting and an opaque hook data pointer.
The for_spawn member of libxl__device_model_starting was annotated with
"first!", suggesting that someone intended to use pointer casting tricks to
move between the outer and inner struct. However the field is a pointer not a
inline struct so this doesn't work (and it isn't used this way anyhow). Remove
the comment, and move the field away from the front for good measure.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
while implementing core dumping functionality for the libxl driver
of libvirt, I discovered an issue with mapping pages of a pv guest.
After dumping the core of a pv guest the domain was not cleared up
properly and some pages were not unmapped. This issue is similar
to the one reported here:
http://lists.xensource.com/archives/html/xen-devel/2011-05/msg01314.html
In xc_domain_dumpcore_via_callback in the file xc_core.c the function
xc_core_arch_map_p2m is called to map P2M_FL_ENTRIES pages to the variable p2m.
But to unmap the pages later, the dinfo->p2m_size has to be set accordingly.
This was not done, instead a variable named p2m_size was set.
This way P2M_FL_ENTRIES was always zero and the pages were left mapped.
[ This change should be considered for backport to relevant trees. ]
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
With some help from Olaf, I've finally got to the bottom of an issue I
came across while trying to implement save/restore in the libvirt
libxenlight driver. After issuing the save operation, the saved domain
was not being cleaned up properly and left in this state from xl's
perspective
xen33:# xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 6821 8 r----- 122.5
(null) 2 2 2 --pssd 10.8
Checking the libvirtd /proc/$pid/maps I found this
7f3798984000-7f3798b86000 r--s 00002000 00:03 4026532097 /proc/xen/privcmd
So not all all pages belonging to the domain were unmapped from
libvirtd. In tools/libxc/xc_domain_save.c we found that P2M_FL_ENTRIES
were being mapped but only P2M_FLL_ENTRIES were being unmapped. The
attached patch changes the unmapping to use the same P2M_FL_ENTRIES
macro. I'm not too familiar with this code though so posting here for
review.
I suspect this was not noticed before since most (all?) processes doing
save terminate after the save and are not long-running like libvirtd.
Ian Campbell writes:
> Looks like I introduced this in 18558:ccf0205255e1, sorry!
>
> I guess it is also wrong in the error path out of map_and_save_p2m_table
> and so we also need [another hunk].
This change should be backported to relevant earlier trees. -iwj
From: Jim Fehlig <jfehlig@novell.com>
From: Ian Campbell <Ian.Campbell@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This is one more place that needs to check for 0 entries
after the AMD p2m-sharing patch made p2m_ram_rw == 0
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
When a device can't be allocated to dom0 by the IOMMU, don't leave
dom0 in the "domain" field. It causes pci_remove_device()
to crash trying to remove the dev from the domain's list of devices
(and was probably the wrong thing to do anyway).
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
These disable-warning options are handled specially by GCC:
(a) they are ignored unless the compiler emits a warning; and
(b) even then they produce a warning rather than an error
To handle this, modify the test invocation of GCC to compile a
fragment of code that will always provoke a warning (integer assigned
to pointer). This works around (a) above.
Then, we grep the compiler's stdout/stderr for the option-under-test,
the presence of which would indicate an "unrecognized command-line
option" warning/error. This works around (b) above, letting us
distinguish between the "integer assigned to pointer" and
"unrecognized command-line option" warnings.
Signed-off-by: Keir Fraser <keir@xen.org>
c/s 23253:a3db6b91f32d causes build failure with gcc 4.4.3-4ubuntu5,
as the compiler can't figure out that the value returned is always
a string literal.
Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com>
Improve busy loop device detection after changeset 22773:02c0af2bf280
The intention is not to find the file to be mounted in the losetup -a
output. What matters are existing mounted files with the same dev:inode
as the new file. So the fix is to apply variable expansion which
happens only without double quotes. Otherwise $dev will contain
newlines for hardlinked files, as mentioned in the commit message from
the changeset above.
losetup -a does also truncate long filenames to 62 chars due to ioctl
limitations. This part is fixed with 2.6.37 where the filename can be
obtained from sysfs. As a result very long filenames will be missed.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
tools/libxl/libxl__build_device_model_args_new/old: The condition is
so rigorous that user has no chance to disable the vnc,
considering what has been done in parse_config_data() by default,
which is not resonable with vnc option in vm-cfg file.
I think, If user explicitly set "vnc=0", vnc should be disabled.
User should have the chance to only use sdl, other remote
display(spice) and even nothing.
Signed-off-by: Zhou Peng <zhoupeng@nfs.iscas.ac.cn>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
At x86_mcinfo_dump(), a little bug at printk information,
illusively= indicate an CMCI/POLLED error to a MCE error, this will
make debug confusing.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
xc_domain_restore.c: In function 'xc_domain_restore':
xc_domain_restore.c:1090:18: error: variable 'prev_pc' set but not
used [-Werror=unused-but-set-variable]
Signed-off-by: Olaf Hering <olaf@aepfle.de>
xc_tmem.c: In function 'xc_tmem_restore':
xc_tmem.c:393:14: error: variable 'save_max_pools' set but not used
[-Werror=unused-but-set-variable]
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Windows SVVP tests require an HPET table even if the HPET is disabled.
This makes sense since the HPET _is_ in the DSDT and, while the OS
does not know that, in principle it's status may change.
(For what it's worth SeaBIOS, in addition to doing this, totally
ignores QEMU's -no-hpet flag and always reports 0x0f for the HPET's
_STA method).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Reduce TLB flushes:
1. When we update the cr3 during VMRUN/VMEXIT emulation
we toggle between n1asid and n2asid forth and back
=> no TLB flush needed
2. Only flush n1asid or n2asid depending on vcpu guest mode
and not both unconditionally.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Reduce TLB flushes:
1. When we update the cr3 during VMRUN/VMEXIT emulation
we toggle between n1asid and n2asid forth and back
=> no TLB flush needed
2. Only flush n1asid or n2asid depending on vcpu guest mode
and not both unconditionally.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Signed-off-by: Keir Fraser <keir@xen.org>
Linux starting with 2.6.36 uses the XSAVEOPT instruction and has
certain code paths that look only at the feature bit reported through
CPUID leaf 0xd sub-leaf 1 (i.e. without qualifying the check with one
evaluating leaf 4 output). Consequently the hypervisor ought to mimic
actual hardware in clearing leaf 0xd output when not supporting xsave.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Split daemonization option out from monitoring a domain for reboot
etc. The 'e' option continues to disable both and a new 'F'(oreground)
option disables only daemonization.
When I'm debugging xl in the foreground this is often the behaviour I
would like.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The adjustments to v->arch.user_regs.eflags and the initialization of
the int80 direct trap must be done earlier (namely before the function
may bail because of inconsistencies between input and stored state on
an already initialised vCPU) so that stored state is consistent, and
for arch_get_info_guest() to not have its eflags related BUG_ON()
triggered.
Further, v->arch.pv_vcpu.ctrlreg[] indices 3 and 1 aren't being kept
up to date while the domain is running, so consistency checks must
instead be done against v->arch.guest_table{,_user}.
Additionally, for 64-bit pv domains, CR1 must also be checked to be
consistent with the kernel mode setting for the vCPU, and the whole
CR1 checking should not be done for 32-bit pv domains.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Adds "make deb", which does a "make dist" build and wraps the
resulting dist/install files in dist/xen-<version>.deb
This is _not_ a "packaged" version of Xen for Debian users, nor is it
intended to compete with anyone else's packaging efforts. In
particular it doesn't do any of the boot-time or fstab fixups needed
to actually start the xen tools. It's just a quick hack for
developers to be able to quickly install and uninstall a Xen build on
a test box.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
These were caused by some declarations happening before the compiler
would have seen the visibility pragma.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Two different vmcb's are used to run l1 guest and l2 guest.
When host xen switches physical FPU to a different cpu while
l1 or l2 guest is running we need to sync CR0.TS bit in the
other vmcb.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Reviewed-by: Uwe Dannowski <Uwe.Dannowski@amd.com>
Reviewed-by: Wei Huang <Wei.Huang2@amd.com>
On error exit from functions, maped pages should be unmapped
and acquired locks released.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Acked-by: Allen Kay <allen.m.kay@intel.com>
gcc 4.6 complains:
io_apic.c: In function 'restore_IO_APIC_setup':
/build/user-xen_4.1.0-3-amd64-zSon7K/xen-4.1.0/debian/build/build-hypervisor_amd64_amd64/xen/include/asm/io_apic.h:150:26:
error: '*((void *)&entry+4)' may be used uninitialized in this
function [-Werror=uninitialized]
io_apic.c:221:32: note: '*((void *)&entry+4)' was declared
here
/build/user-xen_4.1.0-3-amd64-zSon7K/xen-4.1.0/debian/build/build-hypervisor_amd64_amd64/xen/include/asm/io_apic.h:150:26:
error: 'entry' may be used uninitialized in this function
[-Werror=uninitialized]
io_apic.c:221:32: note: 'entry' was declared here
cc1: all warnings being treated as errors
Add functions to read/write an entire IO APIC entry using an explicit
union to allow gcc to spot the initialisation.
Reported as Debian bug #625438, thanks to Matthias Klose.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@novell.com>
future SRAR extension
This patch simplify mce_action(). Basically the 2 set of mce status
flags MCA_... and MCER_... are highly functional similar. This patch
remove the redundant middle-level flag MCA_..., and its related data
structure and function, so that mce_action() logic is more clean and
simpler. This patch also update mem err
handler. intel_memerr_dhandler() will be commonly used by SRAO and
SRAR, so for the extension of future SRAR case, this patch remove the
default fail flag from intel_memerr_dhandler() outside to SRAO/SRAR
level, since only SRAO/SRAR handler itself has the knowledge of how to
handle the failure when mem err handler fail.
Signed-off-by: Liu, Jinsong <jinsong.liu@intel.com>
Ensure that when Xen boots with "iommu=required" it will also insist
that interrupt remapping is supported and enabled. It arranges that
booting with that option on vulnerable hardware will fail, rather than
appearing to succeed but actually being vulnerable to guests.
From: Allen Kay <allen.m.kay@intel.com>
Signed-off-by: Keir Fraser <keir@xen.org>
In the absence of VT-d interrupt remapping support, a device can send
arbitrary APIC messages to host CPUs. One class of attack that results
is to confuse the hypervisor by delivering asynchronous interrupts to
vectors that are expected to handle only synchronous
traps/exceptions.
We block this class of attack by:
(1) setting APIC.TPR=0x10, to block all interrupts below vector
0x20. This blocks delivery to all architectural exception vectors.
(2) checking APIC.ISR[vec] for vectors 0x80 (fast syscall) and 0x82
(hypercall). In these cases we BUG if we detect we are handling a
hardware interrupt -- turning a potentially more severe infiltration
into a straightforward system crash (i.e, DoS).
Thanks to Invisible Things Lab <http://www.invisiblethingslab.com>
for discovery and detailed investigation of this attack.
Signed-off-by: Keir Fraser <keir@xen.org>
The checks in assert_irq and deassert_irq to distinguish interrupts
that have been remapped onto event channels from the others that have
to be injected using the emulated lapic are wrong.
Fix the condition checks using the convenient hvm_domain_use_pirq
function.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
HVM VPMU support can be enabled for AMD Family 12h and 14h processors
by taking the same code path as 10h.
Signed-off-by: Jacob Shin <jacob.shin@amd.com>
On 64-bit Xen, hypercalls from 32-bit HVM guests are handled as
a special case, but not all the hypercalls are corrently redirected
to their compat-mode wrappers. Use compat_* for xen_version,
sched_op and set_timer_op for consistency.
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
Ian Campbell
Jinsong Liu
Markus Gross
Jim Fehlig
Tim Deegan
Keir Fraser
Olaf Hering
George Dunlap
Zhou Peng
Christoph Egger
Paolo Bonzini
Jan Beulich
Ian Jackson
Igor Mammedov
Stefano Stabellini
Jacob Shin