I thought in 0040b649d6 "xen: arm: Only lookup kernel/initrd bootmodule once
while building dom0" that I had identified place_modules as being soon enough,
but I was wrong, since write_properties wants to use it sooner.
Select the initrd boot module in kernel_probe at the same time we select the
kernel to avoid all this.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
XEN_DOMCTL_gdbsx_domstatus is already safe. It loops at most over every vcpu
in a domain and breaks at the first vcpu with an event pending, marking it as
not-pending.
XEN_DOMCTL_gdbsx_pausevcpu had an incorrect bounds check against the vcpu id,
allowing an overflow of d->vcpu[] with an id between d->max_vcpus and
MAX_VIRT_CPUS. It was also able to overflow a vcpus pause count by many
repeated hypercalls.
The bounds check is fixed, and vcpu_pause() has been replaced with
vcpu_pause_by_systemcontroller() which cuts out at 255 uses.
XEN_DOMCTL_gdbsx_unpausevcpu suffered from the same bounds problems as its
pause counterpart, and is fixed in exactly the same way. Despite the
atomic_read(&v->pause_count), this code didn't successfully prevent against an
underflow of the vcpu pause count.
The vcpu_unpause() has been replaced with vcpu_pause_by_systemcontroller()
which correctly prevents against underflow. The printk() is updated to have a
proper guest logging level, and provide more useful information in the XSM
case of one domain having debugger privileges over another.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Which will be used by following patches. Reorder the function declarations
for vcpu/domain pause/unpause to group by vcpu/domain and visually separate
them slightly.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
c/s 3eb1c708ab "properly reference count DOMCTL_{,un}pausedomain hypercalls"
accidentally inverted the use of d->controller_pause_count.
Revert back to how it was originally, i.e. the XEN_DOMCTL_gdbsx_{,un}pausevcpu
hypercalls are only valid for a domain already paused by the system controller.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The code in hvm_send_assist_req_to_ioreq_server() and hvm_do_resume() uses
an event channel port number taken from the page of memory shared with the
emulator. This allows an emulator to corrupt values that are then blindly
used by Xen, leading to assertion failures in some cases. Moreover, in the
case of the default ioreq server the page remains in the guest p2m so a
malicious guest could similarly corrupt those values.
This patch changes the afforementioned functions to get the event channel
port number from an internal structure and also adds an extra check to
hvm_send_assist_req_to_ioreq_server() which will crash the domain should the
guest or an emulator corrupt the port number in the shared page.
Reported-by: Wen Congyang <wency@cn.fujitsu.com>
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
This adds systemd socket activation support for the Ocaml xenstored.
Ocaml lacks systemd library support so we provide our own C helpers
as is done with other functionality lacking on Ocaml.
Active sockets enables oxenstored to be loaded only if required by a system
onto which Xen is installed on. Socket activation is handled by
systemd, once a port for a service which claims a socket is used
systemd will start the required services for it, on demand. For more
details on socket activation refer to Lennart's socket-activation
post regarding this [0].
An important difference with socket activation is that systemd will set
FD_CLOEXEC for us on the socket before giving it to us, we'll sprinkly
the Unix.set_close_on_exec for LSB init next as a separate commit.
Right now this code adds a no-op for this functionality, leaving the
enablement to be done later once systemd is properly hooked into
the build system. The socket activation is ordered in aligment with
the socket activation order passed on to systemd.
[0] http://0pointer.de/blog/projects/socket-activation2.html
Cc: David Scott <dave.scott@eu.citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Vincent Hanquez <Vincent.Hanquez@eu.citrix.com>
Acked-by: Dave Scott <Dave.Scott@citrix.com>
Acked-by: Anil Madhavapeddy <anil@recoil.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
This adds systemd socket activation support for the C xenstored.
Active sockets enable xenstored to be loaded only if required by a system
onto which Xen is installed on. Socket activation is handled by
systemd, once a port for a service which claims a socket is used
systemd will start the required services for it, on demand. For more
details on socket activation refer to Lennart's socket-activation
post regarding this [0].
Right now this code adds a no-op for this functionality, leaving the
enablement to be done later once systemd is properly hooked into
the build system. The socket activation is ordered in aligment with
the socket activation order passed on to systemd.
[0] http://0pointer.de/blog/projects/socket-activation2.html
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
This will be used later for dynamic configuration paths on C code.
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
If domain is created through virsh, then in xl, one could see it
with 'xl list', but with 'xl list --long domU', it reports:
"Domain name must be specified."
The reason is xl config data does not exist but it still tries
to parse_config_data in current code.
Improve list_domain_details:
If len of config data is 0, just pass, do not go forward to
parse_config_data, otherwise, it will meet error like
"Domain name not specified" and exit. This error is not expected,
since if code enters list_domain_details, domain name validness
is already checked and domain does exist.
Length of config data is 0 may means: config data does not exist due
to some reason, like: domain is created by libvirt, or in destroying
domain process config data is cleared but domain fails to clean up.
No matter in which case, list_domain_details could just show empty
info, but not error like "Domain name not specified".
Signed-off-by: Chunyan Liu <cyliu@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
When xenconsoled starts, there will be log lines in the Xen console ring from
boot, even though VIRQ_CON_RING is not yet pending.
Add a force option to handle_hv_logs() which bypasses the event channel check,
allowing xenconsoled to drain the Xen boot messages when it starts, rather
than at the first subsequent time that VIRQ_CON_RING becomes set.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The size of the Xen console ring is runtime configurable, so the statically
sized 16k buffer is not necessarily sufficient. Make repeated
xc_readconsolering() hypercalls while Xen managed to completely fill the
provided buffer.
Also, change the buffer to being static to save on stack space.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
If -Wextra is appended to CFLAGS it will enable all warnings. Previous
options such as -Wno-unused-parameters have no effect anymore. As a
result compilation will fail with gcc-4.3. Newer versions of gcc will
appearently remember -Wno-* options before -Wextra.
Rearrange warning options for gcc so that -Wextra comes before other -W
options. This fixes compilation of stubdom in SLES11.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Compilation fails with gcc-4.3:
tpmback.c: In function 'tpmback_resp':
tpmback.c:148: error: inlining failed in call to 'tpmdev_check_req': call is unlikely and code size would grow
tpmback.c:165: error: called from here
tpmback.c: In function 'new_tpmif':
tpmback.c:384: error: inlining failed in call to '__init_tpmif': call is unlikely and code size would grow
tpmback.c:425: error: called from here
Adjust code to use static instead of inline, it has the same effect.
Change also tpmif_req_ready and tpmif_req_finished before they start to
cause failures.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
gcc-4.3 fails to prove that array indices will remain positive. Add a
hint for the compiler and check the index value before using it.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
They might be in e.g. flash or something but more likely they could
be in a bank of RAM which we aren't handling or in RAM which the
bootloader hasn't told us about for some reason.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Cc: Fu Wei <fu.wei@linaro.org>
Cc: Roy Franz <roy.franz@linaro.org>
Use ENTRY() for function entry points since it ensures correct
alignment where GLOBAL() doesn't. The exception is the initial start
label which must be at offset 0, so just use GLOBAL() to avoid the
possibility of realignment.
Since everything happens to already be aligned there should be no
difference to the actual binary. objdump agrees.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
This avoids having to deal with the 1:1 boot mapping crossing a
section or page boundary.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
If the identity map is created at one level then avoid creating
entries further down the boot page tables, since these will be aliases at
strange virtual address.
For example consider an arm32 system (for simplicity) with Xen loaded at
address 0x40402000. As a virtual address this corresponds to walking offsets 1,
2 and 2 at the first, second and third levels respectively.
When creating the identity map we will therefore create a 1GB super mapping at
0x40000000 for the identity map, which is the one we want to use.
However when considering the second level we will see the offset 2 and create a
2MB mapping in slot 2 of boot_second. Since boot_second is mapped in slot 0 of
boot_first this corresponds to an unwanted mapping from virtual address
0x00400000 to physical address 0x40400000.
We still do not handle the case where the load address is within the 2MB range
starting just after XEN_VIRT_START. This is not a regression but this patch
tries to provide a more useful diagnostic message. We do handle loading at
exactly XEN_VIRT_START.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Level 0 does not support superpage mappings, meaning that systems on where Xen
is loaded above 512GB (I'm not aware of any such systems) the 1:1 mapping on
the boot page tables is invalid.
In order to avoid this issue we need an additional first level page table
mapped by the appropriate L0 slot and containing a 1:1 superpage mapping.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Currently the boot page tables map Xen at XEN_VIRT_START using a 2MB section
mapping. This means that the bootloader must load Xen at a 2MB aligned address.
Unfortunately this is not the case with UEFI on the Juno platform where Xen
fails to boot. Furthermore the Linux boot protocol (which Xen claims to adhere
to) does not have this restriction, therefore this is our bug and not the
bootloader's.
Fix this by adding third level pagetables to the boot time pagetables, allowing
us to map a Xen which is aligned only to a 4K boundary. This only affects the
boot time page tables since Xen will later relocate itself to a 2MB aligned
address. Strictly speaking the non-boot processors could make use of this and
use a section mapping, but it is simpler if all processors follow the same boot
path.
Strictly speaking the Linux boot protocol doesn't even require 4K alignment
(and apparently Linux can cope with this), but so far all bootloaders appear to
provide it, so support for this is left for another day.
In order to use LPAE_ENTRIES in head.S we need to define it in an asm friendly
way.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
[ ijc -- properly format message "- FOO -\r\n" ]
This patch adds support for parsing through multiple AMD container
binaries concatenated together. It is a feature already present in Linux.
Link to linux patch:
http://lkml.kernel.org/r/1370463236-2115-3-git-send-email-jacob.shin@amd.com
Other changes introduced:
- Define HDR_SIZE's explicitly for code clarity.
- Minor cleanup: Remove extra casts in that are used in
install_equiv_cpu_table()
Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Moving straight from fully disabled to x2apic mode is an illegal state
transition, and causes an unconditional #GP fault. Bounce through xapic mode
to avoid the fault.
In addition, avoid bouncing through the various apic modes if the mode is
already correct.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
This is a patch repairing a regression in code previously functional in 4.1.x.
It appears that, during some refactoring work, call to hvm_memory_event_cr0 was lost.
This function was originally called in mov_to_cr() of vmx.c, but the commit
http://xenbits.xen.org/hg/xen-unstable.hg/rev/1276926e3795 abstracted the
original code into generic functions up a level in hvm.c, dropping the call
in the process.
The same issue affected the CR3 and CR4 events, which were fixed in patch
http://xenbits.xensource.com/hg/xen-unstable.hg/rev/7ab899e46347.
Signed-off-by: Tamas K Lengyel <tamas.lengyel@zentific.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Changeset dab11417d
"x86/HVM: consolidate and sanitize CR4 guest reserved bit determination"
did not take into account the fact that dom0 does not have a cpuid policy. As
a result, PVH dom0s would be given unexpected #GP faults on boot.
In addition to the restore case (where the toolstack has not had time to load
a cpuid policy), unconditionally exempt the hardware domain from needing a
policy.
Reported-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Roger Pau Monné <roger.pau@citrix.com>
When shutting down the machine while there are cpus in a cpupool other than
Pool-0 a crash is triggered due to cpupool handling rejecting offlining the
non-boot cpus in other cpupools.
It is easy to detect this case and allow offlining those cpus.
Reported-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Stefan Bader <stefan.bader@canonical.com>
It has been unconditionally enabled for 64bit Xen builds since 2006
c/s 6f562e72 "[XEN][X86_64] USe GLOBAL bit to build user mappings."
Adjust the order of definitions in x86_64/page.h to put the bit definitions
for pte flags together.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Assign modules types based on the order in which they are defined in the FDT.
This is supported only for the dom0 kernel and ramdisk when given as the first
and second modules respectively, similar to how
http://wiki.xen.org/wiki?title=Xen_ARM_with_Virtualization_Extensions/Multiboot&oldid=11824
defined the default types from the bootloader side.
This is compatible with how Xen interprets the modules with x86 multiboot and I
think simplifies things for bootloaders which now need not contain similar
guessing code if they only care about the most basic case.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
This is more natural and better matches how multiboot is actually supposed to
work.
As part of this we need to modify consider_modules to handle Xen not
necessarily being module zero any more. To do this we first register a module
for Xen at the original load address and then update after we have relocated.
This is also fixing a latent issue which is that get_xen_paddr() would not
consider Xen's current physical address when picking the target address which
was buggy because the relocation code cannot handle the possibility of the old
and new locations overlapping.
All callers of consider_modules now consider the full range instead of some
skipping slot 0.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Move the early code for walking the flattened device tree out of device_tree.c.
The intention is that eventually only the proper (i.e. unflattened) device
tree support will live in device_tree.c.
The new home is bootfdt.c to try and better reflect the purpose of the code.
Although in theory this early code could be generic in reality it is pretty ARM
specific, so place it under xen/arch/arm until a second user wants it.
As part of the move rename device_tree_early_init to boot_fdt_info. Drop
device_tree_dump, it is unused.
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>
There isn't really anything Device Tree specific about the early_info, we just
happen to get it from device tree (but in the future it might come e.g. from
UEFI or ACPI or something else).
Move the relevant structs out of device_tree.h and into asm/setup.h and rename to
be more neutral.
For now the code to parse the DT into the now arch specific structs remains in
common code.
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>
When using a multiboot capable bootloader this is exactly the field which
should be used.
Replace the deprecation wording with a reference to the information on the
priority of the bootargs fields.
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>
When we change which PT page we are mapping at a given level then we need to
invalidate any cached mappings further down the tree, otherwise we risk using
them because their offset might match but be based on a different offset
further up the table.
e.g. when remapping first then cur_first_offset and cur_second_offset (which
indicate the currently mapped second and third tables respectively) both become
invalid
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Julien Grall <julien.grall@linaro.org>
Luis R. Rodriguez