When the buffer to be formatted to is too small, the function return
value is expected to be the number of characters that would be printed
(particularly important if that value is then used for allocating a
buffer). Hence incrementing the active pointer must always be
independent of actually storing a character.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
The effect is unchanged, but the processor will be spending most of its time
in the C1 or C1E power state rather than C0.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
The I/O port bitmap holds 8 ports per element, and hence the port number
used when indexing into it should be shifted right by 3 bits, not 4.
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Reviewed-by: Yang Zhang <yang.z.zhang@intel.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
The recommendation is to set a bit in an MSR - do this if the firmware
didn't, considering that otherwise we expose ourselves to a guest
induced DoS.
This is CVE-2013-6885 / XSA-82.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Although MFNs are 64-bit in the hypercall ABI they are most often unsigned
long internally, and therefore be 32-bit on arm32. Physical addresses are
always 64-bit via paddr_t.
This means that the common "mfn << PAGE_SHIFT" pattern risks losing some of
the top bits of the address is high enough. This need not imply a high amount
of RAM, just a sparse physical address map.
The correct form is ((paddr_t)mfn)<<PAGE_SHIFT and we have the pfn_to_paddr
macro which implements this. Grep for PAGE_SHIFT and << and switch to the
macro everywhere we can in the arch specific code. Note that page.h is
included by mm.h which defines the macro and so remains with the open coded
cast. I have inspected the common code matching this pattern and it uses the
correct casts where necessary (x86 also has pfn_to_paddr, so as a further
cleanup we could fix the common code too, but I haven't done that here).
I observed this as failure to boot a guest on midway, due to trying to map a
foreign page which belonged to no guest. I think this likely explains the
crashes which Julien has seen too.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
It is quite inappropriate to keep a hacked up versions of figlet in our source
tree, especially when the purpose of the hackary is just to provide a text to
octal conversion.
This version of figlet contributes a surprisingly large proportion of the
Coverity issues found under xen/ (and therefore attributed against Xen)
Figlet can be found in all distros, so make use of it. We keep xen.flf (being
the Xen figlet font) and replace the hacked up octal transform with a short
python script.
The Xen Makefile has been tweaked in such a way that it still prints the
figlet banner for the build.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
If initializing the ctx's lock fails, don't keep going, but instead
error out.
Coverity-ID: 1055289
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
...from libxl_cpuid_parse_config_xend. value is unsigned so this doesn't
work, and either way the following comparison on it being bigger than 3
does what was intended here anyway.
Coverity-ID: 1055614
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
It could, even if only in theory, be fd 0.
(This is not the same as commit 4b62556b57!)
Coverity-ID: 1055895
Signed-off-by: Matthew Daley <mattd@bugfuzz.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The ptr calculation shall take the offset into the page into account
when ptr is valid.
Reported regression on NetBSD's port-xen with last known working libxen
being rev 2.9. This corrupts the kernel symbol table when the table is
not loaded on a page boundary.
Issue was tracked down by FastIce and Jeff Rizzo. See also
http://mail-index.netbsd.org/port-xen/2013/10/16/msg008088.html
Signed-off-by: Jean-Yves Migeon <jym@NetBSD.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This patch adds a short description of xen-pvdevice to
pci-device-reservations.txt, which contains the canonical list
of device IDs that may be used to create xen-pvdevice instances.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- ran expand to de-tabbify ]
Dietmar noticed that one of these was incorrect, but in actual fact they are
not even used. They are defined as nops in Xen for the benefit of code
imported to Linux which ARM's smpboot.c is not.
Just get rid of them.
Reported-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Load OVMF from (100000000ULL - sizeof(ovmf)) to 0xFFFFFFFF, with proper
rounding down.
Tested with OVMF release build (1 MB) and debug build (2 MB), both
worked fine.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Without flushing dcache the hypervisor couldn't copy the device tree
correctly when booting the kernel dom0 Image (memory with device tree
is corrupted). As the result - when we try to load the kernel dom0
Image - dom0 hungs frequently. This issue is not reproduced with the
kernel dom0 zImage because the zImage decompressor code flushes all
dcache before starting the decompressed kernel Image. When the
hypervisor loads the kernel image or initrd, this memory region
isn't corrupted because the hypervisor code flushes the dcache.
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall<julien.grall@linaro.org>
This should result in QEMU *not* adding the xen-platform device.
Since QEMU 1.6, this can be achieved by using a different qemu machine.
The one used by libxl is "xenfv", but using QEMU >=1.6 with "-machine
pc,accel=xen" works as well with only one difference compared to
"xenfv", there is no xen-platform device.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On the X-gene platform there are resources up this high which must be mapped
to dom0.
Remove the first level page from the p2m->pages list since it is actually two
pages and must be freed as such. Do so in p2m_teardown.
I've also punted on the implementation of dump_p2m_lookup for high
addresses...
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Purely cosmetic, put a blank line after the early memory map to separate it
from the subsequent information. This looks better since the memory map is
preceded by a blank line too.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Setting synchronous console ensures that any printk hits the buffer
immediately and that any outstanding queued log messages are flushed. This
ensures that such log messages are not being printed while the secondary CPU
may be using early_printk during early bringup.
Signed-of-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Keir Fraser <keir@xen.org>
Otherwise the results of the shifting can be undefined and/or sign extended.
Most registers are 32-bit on both arm32 and arm64 and hence are just unsigned
ints, however HCR is 64-bit on arm64 and therefore is unsigned long.
Pointed out in the context of HCR_* by Pranavkumar Sawargaonkar.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Pranavkumar Sawargaonkar <psawargaonkar@apm.com>
Currently the hardcoded use of GUEST_EVTCHN_PPI is problematic if that is a
real PPI on the platform.
We really need to be smarter about selecting an unused PPI but in the meantime
we can at least give the platform code the option of hardcoding a number which
works for the platform.
Hardcode a suitable PPI on the Xgene platform.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
On some platforms the pages are placed at a 64K stride instead of as
contiguous 4K pages.
This is because the ARM64 architecture allows for page sizes of 4/16/64K in
the MMU so a larger stride allow more granular control of mappings. We only
currently support 4K.
Use this quirk on the xgene platform.
This should ideally be fixed by an extension to the device tree bindings as
described in http://www.spinics.net/lists/devicetree/msg10473.html especially
http://www.spinics.net/lists/devicetree/msg10478.html. However for the time
being a platform specific quirk will do.
Note that we always map the GICV to the guest (including dom0) at a 4K stride
length and this is reflected in the DTB passed to the guest.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Extracted from "Basic Platform support for APM X-Gene Storm."
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
Reworked into generic 8250 driver, use EARLY_UART_REG_SHIFT.
While there observe a missing shift in the arm32 version (UART_THR is zero so
it doesn't really matter). Changed for consistency.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
- For now, iommu is required for PVH dom0. Check for that.
- For pvh, we need to do mfn_to_gmfn before calling mapping function
intel_iommu_map_page/amd_iommu_map_page which expects a gfn.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
For a pass-through device with MSI-x capability, when guest tries
to unmask the MSI-x interrupt for the passed through device, xen
doesn't clear the mask bit for MSI-x in hardware in the following
scenario, which will cause network disconnection:
1. Guest masks the MSI-x interrupt
2. Guest updates the address and data for it
3. Guest unmasks the MSI-x interrupt (This is the problematic step)
In the step #3 above, Xen doesn't handle it well. When guest tries
to unmask MSI-X interrupt, it traps to Xen, Xen just returns to Qemu
if it notices that address or data has been modified by guest before,
then Qemu will update Xen with the latest value of address/data by
hypercall. However, in this whole process, the MSI-X interrupt unmask
operation is missing, which means Xen doesn't clear the mask bit in
hardware for the MSI-X interrupt, so it remains disabled, that is why
it loses the network connection.
This patch fixes this issue.
Signed-off-by: Feng Wu <feng.wu@intel.com>
Only latch the address if the guest really is unmasking the entry.
Clean up the entire change.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
In some cases, such as suffering a queued-invalidation timeout while
performing an iommu_crash_shutdown(), Xen can end up reentering the crash
path. Previously, this would result in a deadlock in one_cpu_only(), as the
test_and_set_bit() would fail.
The crash path is not reentrant, and even if it could be made to be so, it is
almost certain that we would fall over the same reentry condition again.
The new code can distinguish a reentry case from multiple cpus racing down the
crash path. In the case that a reentry is detected, return back out to the
nested panic() call, which will maybe_reboot() on our behalf. This requires a
bit of return plumbing back up to kexec_crash().
While fixing this deadlock, also fix up an minor niggle seen recently from a
XenServer crash report. The report was from a Bank 8 MCE, which had managed
to crash on all cpus at once. The result was a lot of stack traces with cpus
in kexec_common_shutdown(), which was infact the inlined version of
one_cpu_only(). The kexec crash path is not a hotpath, so we can easily
afford to prevent inlining for the sake of clarity in the stack traces.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Anything else would allow for privilege escalation.
This is CVE-2013-4554 / XSA-76.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Coverity ID 1055652
(See the code comment.)
This is CVE-2013-4553 / XSA-74.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Update the comment to clarify that libxl_sigchld_owner_libxl_always
implies having only one libxl_ctx, and that
libxl_sigchld_owner_mainloop requires one call to
libxl_childproc_exited per ctx.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Checking the logfile_w fd for -1 on failure is no longer true, because
libxl__create_qemu_logfile will now return ERROR_FAIL on failure which
is -3.
While there also add an error check for opening /dev/null.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Right now Xen sets the WP and NE flags on cr0 for PVH, which are not
needed in order to boot with paging enabled. The same happens with
cr4, at least on my system OSFXSR, OSXMMEXCPT and MCE are enabled by
default when there's no need.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Acked-by: Mukesh Rathor <mukesh.rathor@oracle.com>
Acked-by: Eddie Dong <eddie.dong@intel.com>
Jan Beulich
Andrew Cooper
Matthew Daley
Ian Campbell
Jean-Yves Migeon
Paul Durrant
Wei Liu
Oleksandr Dmytryshyn
Anthony PERARD
Pranavkumar Sawargaonkar
Mukesh Rathor
Feng Wu
Ian Jackson
Roger Pau Monne
Tim Deegan