Having an off by default option allowing guests to join
_any_ shared pool is not very secure.
Lets eliminate tmem_shared_auth bootup option (which
was disabled by default) and have the code force this by default.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
which surprisingly (or maybe not) looks like
XEN_SYSCTL_TMEM_OP_SET_POOLS.
This hypercall came about, as explained in docs/misc/tmem-internals.html:
When tmem was first proposed to the linux kernel mailing list
(LKML), there was concern expressed about security of shared ephemeral
pools. The initial tmem implementation only
required a client to provide a 128-bit UUID to identify a shared pool, and the
linux-side tmem implementation obtained this UUID from the superblock of the
shared filesystem (in ocfs2). It was
pointed out on LKML that the UUID was essentially a security key and any
malicious domain that guessed it would have access to any data from the shared
filesystem that found its way into tmem.
..
As a result, a Xen boot option -- tmem_shared_auth; -- was
added. The option defaults to disabled,
but when it is enabled, management tools must explicitly authenticate (or may
explicitly deny) shared pool access to any client.
On Xen, this is done with the xm tmem-shared-auth command.
"
However the implementation has some rather large holes:
a) The hypercall was accessed from any guest.
b) If the ->domain id value is 0xFFFF then one can toggle the
tmem_global.shared_auth knob on/off. That with a)
made it pretty bad.
c) If one toggles the tmem_global.shared_auth off, then the
'tmem_shared_auth=1' bootup parameter is ignored and
one can join any shared pool (if UUID is known)!
d) If the 'tmem_shared_auth=1' and tmem_global.shared_auth is
set to 1, then one can only join an shared pool if the
UUID has been set by 'xl tmem-shared-auth'. Otherwise
the joining of a pool fails and a non-shared pool is
created (without errors to guest). Not exactly sure if
the shared pool creation at that point should error out
or not.
e) If a guest is migrated, the policy values (which UUID
can be shared, whether tmem_global.shared_auth is set, etc)
are completely ignored.
This patch only fixes a) and only allows the hypercall to
be called by the control domain. Subsequent patches will
fix the remaining issues.
We also have to call client_create as the guest at this
point may not have done any tmem hypercalls - and hence
the '->tmem' from 'struct domain' is still NULL. Us calling
client_create fixes this.
Acked-by: Wei Liu <wei.liu2@citrix.com> [libxc changes]
Reviewed-by: Jan Beulich <jbeulich@suse.com> [hypervisor changes]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This used to be done under TMEM_RESTORE_NEW which was an hypercall
accessible by the guest. However there are couple of reasons
not to do it:
- No checking of domid on TMEM_RESTORE_NEW which meant that
any guest could create TMEM pools for other guests.
- The guest can already create pools using TMEM_NEW_POOL
(which is limited to guest doing the hypercall)
- This functionality is only needed during migration - there
is no need for the guest to have this functionality.
However to move this we also have to allocate the 'struct domain'
->tmem pointer. It is by default set to NULL and would be initialized
via the guest do_tmem() hypercalls. Presumarily that was the
initial reason that TMEM_RESTORE_NEW was in the guest accessible
hypercalls.
Acked-by: Wei Liu <wei.liu2@citrix.com> [libxc change]
Reviewed-by: Jan Beulich <jbeulich@suse.com> [hypervisor changes]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
This is the ABI for the two halves of a para-virtualized
display driver.
This protocol aims to provide a unified protocol which fits more
sophisticated use-cases than a framebuffer device can handle. At the
moment basic functionality is supported with the intention to extend:
o multiple dynamically allocated/destroyed framebuffers
o buffers of arbitrary sizes
o better configuration options including multiple display support
Note: existing fbif can be used together with displif running at the
same time, e.g. on Linux one provides framebuffer and another DRM/KMS
Future extensions to the existing protocol may include:
o allow display/connector cloning
o allow allocating objects other than display buffers
o add planes/overlays support
o support scaling
o support rotation
Note, that this protocol doesn't use ring macros for
bi-directional exchange (PV calls/9pfs) bacause:
o it statically defines the use of a single page
for the ring buffer
o it uses direct memory access to ring's contents
w/o memory copying
o re-uses the same idea that kbdif/fbif use
which for this use-case seems to be appropriate
==================================================
Rationale for introducing this protocol instead of
using the existing fbif:
==================================================
1. In/out event sizes
o fbif - 40 octets
o displif - 40 octets
This is only the initial version of the displif protocol
which means that there could be requests which will not fit
(WRT introducing some GPU related functionality
later on). In that case we cannot alter fbif sizes as we need to
be backward compatible an will be forced to handle those
apart of fbif.
2. Shared page
Displif doesn't use anything like struct xenfb_page, but
DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct
xendispl_resp) which is a better and more common way.
Output events use a shared page which only has in_cons and in_prod
and all the rest is used for incoming events. Here struct xenfb_page
could probably be used as is despite the fact that it only has a half
of a page for incoming events which is only 50 events. (consider
something like 60Hz display)
3. Amount of changes.
fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
events, so it looks like it is easier to get fb support into displif
than vice versa. displif at the moment has 6 requests and 1 event,
multiple connector support, etc.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Add ABI for the two halves of a para-virtualized
sound driver to communicate with each other.
The ABI allows implementing audio playback and capture as
well as volume control and possibility to mute/unmute
audio sources.
Note: depending on the use-case backend can expose more sound
cards and PCM devices/streams than the underlying HW physically
has by employing SW mixers, configuring virtual sound streams,
channels etc. Thus, allowing fine tunned configurations per
frontend.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
Signed-off-by: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Signed-off-by: Iurii Konovalenko <iurii.konovalenko@globallogic.com>
Currently in xc_interface_open, xch->fmem is not initialized
and in some rare case the code fails before ever assigning a value
to it.
I got this in master:
$ sudo ./xl/xl run
xencall: error: Could not obtain handle on privileged command interface: No such file or directory
Segmentation fault
This initializes the whole xch_buff to 0.
Signed-off-by: Seraphime Kirkovski <kirkseraph@gmail.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The use of guest_handle_okay() here (as introduced by the XSA-29 fix)
is insufficient here, guest_handle_subrange_okay() needs to be used
instead.
Note that the uses are okay in
- XENMEM_add_to_physmap_batch handling due to the size field being only
16 bits wide,
- livepatch_list() due to the limit of 1024 enforced on the
number-of-entries input (leaving aside the fact that this can be
called by a privileged domain only anyway),
- compat mode handling due to counts there being limited to 32 bits,
- everywhere else due to guest arrays being accessed sequentially from
index zero.
This is CVE-2017-7228 / XSA-212.
Reported-by: Jann Horn <jannh@google.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Although it's still always set to VIOAPIC_NUM_PINS (48).
Add a new field to the hvm_ioapic struct to contain the number of pins (number
of IO redirection table entries) and turn the redirection table into a variable
sized array.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Rearrange the fields of hvm_irq so that gsi_assert_count can be converted into
a variable size array and add a new field to account the number of GSIs.
Due to this changes the irq member in the hvm_domain struct also needs to
become a pointer set at runtime.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Rename it to NR_HVM_DOMU_IRQS, and get it's value from the size of the DomU vIO
APIC redirection table.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
When kexec_do_unload calls kexec_swap_images to get the old kexec_image to
free, it passes NULL for the new kexec_image pointer. The new slot wasn't being
cleared in such a case, leading to a stale pointer being left behind in the
kexec_image array and Xen panics in subsequent load/unload operations.
Signed-off-by: Bhavesh Davda <bhavesh.davda@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
So that the function can be called from other files without adding prototypes
to each of them.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
Introduce a macro to get a pointer to the hvm_irq for a HVM domain. No
functional change.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com> [VT-d]
Acked-by: Jan Beulich <jbeulich@suse.com>
This is required in order to have a variable number of vIO APIC pins, instead
of the current fixed value (48). Note that this patch only expands the fields
of the hvm_vioapic struct, without actually introducing any new fields or
functionality.
The reason to expand the hvm_vioapic structure instead of the hvm_hw_vioapic
one is that the variable number of pins functionality is only going to be used
by the hardware domain, so no modifications are needed to the save format.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
parse_vwfi runs after init_traps on cpu0, potentially resulting in the
wrong HCR_EL2 for it. Secondary cpus boot after parse_vwfi, so in their
case init_traps will write the correct set of flags to HCR_EL2.
For cpu0, fix the issue by changing HCR_EL2 setting from a new
presmp_initcall.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
When booting using ACPI, not all MMIOs can be discovered by parsing the
static tables or the UEFI memory map. A lot of them will be described in
the DSDT. However, Xen does not have an AML parser which requires us to
find a different approach.
During the first discussions on supporting ACPI (see design doc [1]), it
was decided to rely on the hardware domain to make a request to the
hypervisor to map the MMIO region in stage-2 page table before accessing
it. This approach works fine if the OS has limited hooks to modify the
page tables.
In the case of Linux kernel, notifiers have been added to map
the MMIO regions when adding a new AMBA/platform device. Whilst this is
covering most of the MMIOs, some of them (e.g OpRegion, ECAM...) are not
related to a specific device or the driver is not using the
AMBA/platform API. So more hooks would need to be added in the code.
Various approaches have been discussed (see [2]), one of them was to
create stage-2 mappings seamlessly in Xen upon hardware memory faults.
This approach was first ruled out because it relies on the hardware
domain to probe the region before any use. So this would not work when
DMA'ing to another device's MMIO region when the device is protected by
an SMMU. It has been pointed out that this is a limited use case compare
to DMA'ing between MMIO and RAM.
This patch implements this approach. All MMIOs region will be mapped in
stage-2 using p2m_mmio_direct_c (i.e normal memory outer and inner
write-back cacheable). The stage-1 page table will be in control of the
memory attribute. This is fine because the hardware domain is a trusted
domain.
Note that MMIO will only be mapped on a data abort fault. It is assumed
that it will not be possible to execute code from MMIO
(p2m_mmio_direct_c will forbid that).
As mentioned above, this solution will cover most of the cases. If a
platform requires to do DMA'ing to another device's MMIO region without
any access performed by the OS. Then it will be expected to have
specific platform code in the hypervisor to map the MMIO at boot time or
the OS to use the existing hypercalls (i.e XENMEM_add_to_add_physmap{,_batch})
before any access.
[1] https://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] https://marc.info/?l=linux-arm-kernel&m=148469169210500&w=2
Signed-off-by: Julien Grall <julien.grall@arm.com>
Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
If ocaml.m4 didn't find ocamlopt, disable all the ocaml builds.
Currently our Makefiles do not work properly when the native code
compiler (`ocamlopt') is not available. In principle this should be
fixed to fall back to bytecode, but this is not a task for this stage
of the Xen 4.9 release.
Without this change, we cannot build on systems with only ocamlc.
That includes Debian jessie ARM64, as used on the new ARM64 hardware
in the Xen Project CI test lab.
When the Makefiles are fixed, this commit should be reverted.
Committers: Please rerun autogen.sh.
CC: Julien Grall <julien.grall@arm.com>
CC: Christian Lindig <christian.lindig@citrix.com>
CC: Jonathan Ludlam <Jonathan.Ludlam@citrix.com>
CC: David Scott <dave@recoil.org>
CC: Wei Liu <wei.liu2@citrix.com>
Tested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Remove all unused functions from tdb.c. This will reduce code size of
xenstored and - more important - of xenstore stubdom.
tdb.c hasn't been updated to a newer version since its introduction in
2005. Any backport of bug fixes or update to a new version will need
major work, so there is no real downside to remove not needed code.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
The handling of transactions in xenstored is rather clumsy today:
- Each transaction in progress is keeping a local copy of the complete
xenstore data base
- A transaction will fail as soon as any node is being modified outside
the transaction
This is leading to a very bad behavior in case of a large xenstore.
Memory consumption of xenstored is much higher than necessary and with
many domains up transactions failures will be more and more common.
Instead of keeping a complete copy of the data base for each
transaction store the transaction data in the same data base as the
normal xenstore entries prepended with the transaction in the single
nodes either read or modified. At the end of the transaction walk
through all nodes accessed and check for conflicting modifications.
In case no conflicts are found write all modified nodes to the data
base without transaction identifier.
Following tests have been performed:
- create/destroy of various domains, including HVM with ioemu-stubdom
(xenstored and xenstore-stubdom)
- multiple concurrent runs of xs-test over several minutes
(xenstored and xenstore-stubdom)
- test for memory leaks of xenstored by dumping talloc reports before
and after the tests
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Instead of setting errno and returning true or false return the error
value directly.
In order to ensure all call sites have been changed according to the
modification rename the functions to xs_*.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
This patch is based on the implementation of ARM64, it introduces
alternative runtime patching to ARM32. This allows to patch assembly
instruction at runtime to either fix hardware bugs or optimize for
certain hardware features on ARM32 platform.
Xen hypervisor is using ARM execution state only on ARM32 platform,
Thumb is not used. So, the Thumb only branch instructions (CBZ, CBNZ,
TBB and TBH) are not considered in alternatives.
The left ARM32 branch instructions are BX, BLX, BL and B. The
instruction BX is taking a register in parameter, so we don't need to
rewrite it. The instructions BLX, BL and B are using the similar
encoding for the offset and will avoid specific case when extracting
and updating the offset.
In this patch, we include alternative.h header file to livepatch.c
directly for ARM32 compilation issues. When the alternative patching
config is enabled, the livepatch.c will use the alternative functions.
In this case, we should include the alternative header file to this
file. But for ARM64, it does not include this header file directly.
It includes this header file indirectly through:
sched.h->domain.h->page.h->alternative.h.
But, unfortunately, the page.h of ARM32 doesn't include alternative.h,
and we don't have the reason to include it to ARM32 page.h now. So we
have to include the alternative.h directly in livepatch.c.
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
MEM_LOG() is just a thin wrapper around gdprintk(), obscuring some of the
common information. Inline it, and take the opportunity to correct some of
the printked information.
Some corrections, each where appropriate:
* Correction of pfn/mfn terms and consistent use of PRI_pfn/mfn
* s!I/O!MMIO!
* Consistently represent domains using d%d notation
* Use 0x prefix for otherwise unqualified hex numbers
* Remove "ptwr_emulate:" prefix, as the embedded __func__ is already clear
* Provide more useful slot information
* Delete some not-very-helpful lines entirely
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
ACPICA commit 9f7c3e148f440049615e2791d73b292f65692d7e
The most recent version of the IORT specification adds in a definition
for a subtable to describe SMMUv3 devices; there is already a subtable
for SMMUv1/v2 devices.
Add in the definition of the subtable, add in the code to compile it,
and add in a template for it.
Link: https://github.com/acpica/acpica/commit/9f7c3e14
Signed-off-by: Al Stone <ahs3@redhat.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit 4ac78baf88d85c49883fcc87d31198ebe408e54d]
Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca
This patch adds support for IORT (IO Remapping Table) in iasl.
Note that some field names are modified to shrink their length or the
decompiled IORT ASL will contain fields with ugly ":" alignment.
The IORT contains field definitions around "Memory Access Properties". This
patch also adds support to encode/decode it using inline table.
This patch doesn't add inline table support for the SMMU interrupt fields
due to a limitation in current ACPICA data table support. Lv Zheng.
Link: https://github.com/acpica/acpica/commit/5de82757
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf]
Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
There are quite a few of these, and as the option is a development one
only, duplicate symbol names should not be an issue there. In other
environments allow the user to control this, unless Live patching is
enabled.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
added code to provide an 'laptop/slate mode' ACPI device to guests.
When present this device is used by Microsoft Windows to bind a HID
driver which controls whether the Windows desktop appearance is optimized
for laptop/desktop or slate/tablet PCs. The mechanism for switching
between modes is to open a handle to this driver and write a byte of
arbitrary data.
This patch documents xenstore keys such that a PV agent running in a
Windows guest can advertise the capability to, and receive instruction
from, a toolstack to cause such a mode switch.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Commit 4c8153d9 "add ACPI device for Windows laptop/slate mode switch"
added code that makes use of a new xenstore guest platform key called
'acpi_laptop_slate'. This path needs to be added to the documentation.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
A number of changes have been made to how we determine whether TSC
is emulated (e.g. commit 4fc380ac00 ("x86/time: don't use virtual TSC
if host and guest frequencies are equal")).
Update the man page to reflect those changes
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
When using _PAGE_PSE_PAT as base for a negated bit mask make sure it is
propagated to 64 bits when applied to a 64 bit value.
There seems to be only one place where this is a problem, so fix this
by casting _PAGE_PSE_PAT to 64 bits there.
Not doing so will probably lead to problems on hosts with more than
16 TB of memory.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@citrix.com>
While I was using the alternative patching in the SErrors patch series [1].
I used a branch instruction as alternative instruction.
ALTERNATIVE("nop",
"b skip_check",
SKIP_CHECK_PENDING_VSERROR)
Unfortunately, I got a system panic message with this code:
(XEN) build-id: f64081d86e7e88504b7d00e1486f25751c004e39
(XEN) alternatives: Patching with alt table 100b9480 -> 100b9498
(XEN) Xen BUG at alternative.c:61
(XEN) ----[ Xen-4.9-unstable arm32 debug=y Tainted: C ]----
(XEN) CPU: 0
(XEN) PC: 00252b68 alternative.c#__apply_alternatives+0x128/0x1d4
(XEN) CPSR: 800000da MODE:Hypervisor
(XEN) R0: 00000000 R1: 00000000 R2: 100b9490 R3: 100b949c
(XEN) R4: eafeff84 R5: 00000000 R6: 100b949c R7: 10079290
(XEN) R8: 100792ac R9: 00000001 R10:100b948c R11:002cfe04 R12:002932c0
(XEN) HYP: SP: 002cfdc4 LR: 00239128
(XEN)
(XEN) VTCR_EL2: 80003558
(XEN) VTTBR_EL2: 0000000000000000
(XEN)
(XEN) SCTLR_EL2: 30cd187f
(XEN) HCR_EL2: 000000000038663f
(XEN) TTBR0_EL2: 00000000bff09000
(XEN)
(XEN) ESR_EL2: 00000000
(XEN) HPFAR_EL2: 0000000000000000
(XEN) HDFAR: 00000000
(XEN) HIFAR: 00000000
(XEN)
(XEN) Xen stack trace from sp=002cfdc4:
(XEN) 00000000 00294328 002e0004 00000001 10079290 002cfe14 100b9490 00000000
(XEN) 10010000 10122700 00200000 002cfe1c 00000080 00252c14 00000000 002cfe64
(XEN) 00252dd8 00000007 00000000 000bfe00 100b9480 100b9498 002cfe1c 002cfe1c
(XEN) 10010000 10122700 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 002ddf30 00000000 003113e8 0030f018 002cfe9c
(XEN) 00238914 00000002 00000000 00000000 00000000 0028b000 00000002 00293800
(XEN) 00000002 0030f238 00000002 00290640 00000001 002cfea4 002a2840 002cff54
(XEN) 002a65fc 11112131 10011142 00000000 0028d194 00000000 00000000 00000000
(XEN) bdffb000 80000000 00000000 c0000000 00000000 00000002 00000000 c0000000
(XEN) 002b8060 00002000 002b8040 00000000 c0000000 bc000000 00000000 c0000000
(XEN) 00000000 be000000 00000000 00112701 00000000 bff12701 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000018 00000000 00000001 00000000
(XEN) 9fece000 80200000 80000000 00400000 00200550 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) Xen call trace:
(XEN) [<00252b68>] alternative.c#__apply_alternatives+0x128/0x1d4 (PC)
(XEN) [<00239128>] is_active_kernel_text+0x10/0x28 (LR)
(XEN) [<00252dd8>] alternative.c#__apply_alternatives_multi_stop+0x1c4/0x204
(XEN) [<00238914>] stop_machine_run+0x1e8/0x254
(XEN) [<002a2840>] apply_alternatives_all+0x38/0x54
(XEN) [<002a65fc>] start_xen+0xcf4/0xf88
(XEN) [<00200550>] arm32/head.o#paging+0x94/0xd8
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at alternative.c:61
(XEN) ****************************************
This panic was triggered by the BUG(); in branch_insn_requires_update.
That's because in this case the alternative patching needs to update the
offset of the branch instruction. But the new target address of the branch
instruction could not pass the check of is_active_kernel_text();
The reason is that: When Xen is booting, it will call apply_alternatives_all
to do patching with alternative tables. In this progress, we should update
the offset of branch instructions if required. This means we should modify
the Xen text section. But Xen text section is marked as read-only and we
configure the hardware to not allow a region to be writable and executable at
the same time. So we re-map Xen in a temporary area for writing. In this case,
the calculation of the new target address of the branch instruction is based
on this re-mapped area. The new target address will point to a value in the
re-mapped area. But we haven't registered this area as an active kernel text.
So the check of is_active_kernel_text will always return false.
We have to register the re-mapped Xen area as a virtual region temporarily to
solve this problem.
1. https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg01939.html
Signed-off-by: Wei Chen <Wei.Chen@arm.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
The use of seabios defconfig kills boot performance of Windows guests
because the default is for the int13 handler to use PIO when accessing
the emulated IDE device.
By instead using a canned configuration with the ATA settings overridden
to enable DMA access (and also wider PIO) boot performance is markedly
improved without the need to use a different (and possibly not supported)
device model.
This patch adds the canned configuration into tools/firmware and modifies
the Makefile rule to copy it into place.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
colo_merge_secondary_dirty_bitmap() unconditionally free()s the .data
member of its local xc_sr_record structure rec on its exit path.
However, if the initial call to read_record() fails then this member is
uninitialised. Initialise it.
Signed-off-by: Joshua Otto <jtotto@uwaterloo.ca>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Add functions to libxl to setup a Xen 9pfs frontend/backend connection.
Add support to xl to parse a 9pfs option in the VM config file, in the
following format:
p9=["tag=share_dir,security_model=none,path=/root/share_dir"]
where tag identifies the 9pfs share and it is required to mount it on
the guest side, path is the path of the filesystem to share and the only
security_model supported is "none" which means that files are stored
using the same credentials as they are created on the guest (no user
ownership squash or remap).
Signed-off-by: Stefano Stabellini <stefano@aporeto.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
vlddqu is encoded with 0xf2 which causes it to fall into the Scalar general
case in x86_decode_twobyte(). However, it really does have just two operands,
so must remain TwoOp
AFL discovered that the instruction c5 5b f0 3c e5 95 0a cd 63 was considered
valid despite it being a two operand instruction and VEX.vvvv having the value
11. The resulting use in a stub yielded #UD.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
For information related to transaction conflicts, potentially frequent
logging at "info" priority has been changed to "debug" priority, and
once per two minutes there is an "info" priority summary.
Additional detailed logging has been added at "debug" priority.
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
In the main loop, when choosing the timeout for the select function
call, we were setting it so as to wake up to issue conflict-credit to
any domains that could accept it. When xenstore is idle, this would
mean waking up every 50ms (by default) to do no work. With this
commit, we check whether any domain is below its cap, and if not then
we set the timeout for longer (the same timeout as before the
conflict-protection feature was added).
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
Reviewed-by: Jonathan Davies <jonathan.davies@citrix.com>
The packet telling us to end the transaction has always carried an
argument telling us whether to commit.
If the transaction made no modifications to the tree, now we ignore
that argument and do not commit: it is just a waste of effort.
This makes read-only transactions immune to conflicts, and means that
we do not need to store any of their details in the history that is
used for assigning blame for conflicts.
We count a transaction as a read-only transaction only if it contains
no operations that modified the tree.
This means that (for example) a transaction that creates a new node
then deletes it would NOT count as read-only, even though it makes no
change overall. A more sophisticated algorithm could judge the
transaction based on comparison of its initial and final states, but
this would add complexity and computational cost.
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
Reviewed-by: Jonathan Davies <jonathan.davies@citrix.com>
We already avoid inter-domain conflicts but now allow intra-domain
conflicts. Although there are no known practical examples of a domain
that might perform operations that conflict with its own transactions,
this is conceivable, so here we avoid changing those semantics
unnecessarily.
When a transaction commit fails with a conflict and we look through
the history of commits to see which connection(s) to blame, ignore
historical commits that were made by the same connection as the
failing commit.
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
Reviewed-by: Jonathan Davies <jonathan.davies@citrix.com>
Blame each connection found to have made a commit that would cause this
transaction to fail. Each blamed connection is penalised by having its
conflict-credit decremented.
Note the change in semantics for the replay function: we no longer stop after
finding the first operation that can't be replayed. This allows us to identify
all operations that conflicted with this transaction, not just the one that
conflicted first.
Signed-off-by: Jonathan Davies <jonathan.davies@citrix.com>
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
v1 Reviewed-by: Christian Lindig <christian.lindig@citrix.com>
Changes since v1:
* use correct log levels for informational messages
Changes since v2:
* fix the blame algorithm and improve logging
(fix was reviewed by Jonathan Davies)
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
Since the list of historic activity cannot grow without bound, it is safe to use
this to track commits.
Signed-off-by: Jonathan Davies <jonathan.davies@citrix.com>
Reviewed-by: Thomas Sanders <thomas.sanders@citrix.com>
The history of commits is to be used for working out which historical
commit(s) (including atomic writes) caused conflicts with a
currently-failing commit of a transaction. Any commit that was made
before the current transaction started cannot be relevant. Therefore
we never need to keep history from before the start of the
longest-running transaction that is open at any given time: whenever a
transaction ends (with or without a commit) then if it was the
longest-running open transaction we can delete history up until start
of the the next-longest-running open transaction.
Some transactions might stay open for a very long time, so if any
transaction exceeds conflict_max_history_seconds then we remove it
from consideration in this context, and will not guarantee to keep
remembering about historical commits made during such a transaction.
We implement this by keeping a list of all open transactions that have
not been open too long. When a transaction ends, we remove it from the
list, along with any that have been open longer than the maximum; then
we delete any history from before the start of the longest-running
transaction remaining in the list.
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
Reviewed-by: Jonathan Davies <jonathan.davies@citrix.com>
Reviewed-by: Christian Lindig <christian.lindig@citrix.com>
There is no need to record "read" operations as they will never cause another
transaction to fail.
Signed-off-by: Jonathan Davies <jonathan.davies@citrix.com>
Reviewed-by: Thomas Sanders <thomas.sanders@citrix.com>
Forward port to xen-unstable:
* Remove Xenbus.Xb.Op.Restrict
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Add ability to track xenstore tree operations -- either non-transactional
operations or committed transactions.
For now, the call to actually retain commits is commented out because history
can grow without bound.
For now, we call record_commit for all non-transactional operations. A
subsequent patch will make it retain only the ones with side-effects.
Signed-off-by: Jonathan Davies <jonathan.davies@citrix.com>
Signed-off-by: Thomas Sanders <thomas.sanders@citrix.com>
Reviewed-by: Christian Lindig <christian.lindig@citrix.com>
Konrad Rzeszutek Wilk