If IA32_MISC_ENABLE[22] is set by the BIOS, CPUID.0.EAX will be limited to 3.
Lift this limit before considering whether to query CPUID.7[ECX=0].EBX for
features.
Without this change, dom0 is able to see this feature leaf (as the limit was
subsequently lifted), and will set features appropriately in HVM domain cpuid
policies.
The specific bug XenServer observed was the advertisement of the FSGSBASE
feature, but an inability to set CR4.FSGSBASE as Xen considered the bit to be
reserved as cpu_has_fsgsbase incorrectly evaluated as false.
This is a regression introduced by c/s 44e24f8567 "x86: don't call
generic_identify() redundantly" where the redundant call actually resampled
CPUID.7[ECX=0] properly to obtain the feature flags.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Missed cleaning up this cast as part of 0aacc28.
Doing that here; and we can remove 'off' variable as well,
just use *offset in it's place.
Signed-off-by: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
... instead of open-coding them or not using them at all. This in
particular fixes a build (and presumably also runtime) problem on old
enough libc due to the recent introduction of a use of O_CLOEXEC. The
other two changes are only of cleanup kind.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
There is nothing vcpu-specific about hpet_init(); all it does is follow the
vcpu's domain pointer to get at the domain vhpet state.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
This moves all generic path variables to a new the config/Paths.mk.in
input source file to be processed at configure time, tons of files use
these so this just share them. This also paves the way to let us
easily dynamically configure these with autoconf, for now we leave the
same presets as was present before.
This work was prompted by looking for an autoconf way to do
replacements for the hotplug global file, while at it I realized
that a few other files use the same variables and have in places
around the tree the same constructs for generating their own
files. This makes use of the old buildmakevars2file() but generalizes
the definition of the paths at configure time and spreads the
new definitions out throughout the build system.
This has no impact on building the hypervisor and extras/mini-os,
you do not need to, and are not expected to, run configure to build
those targets.
While at it lets add some documentation on the for the two files on
the source file, we can expand further details on the wiki [0].
[0] http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran autogen.sh ]
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>
Don Slutz