This is in preparation for the next patch, and mtrr_def_type_msr_set()
and mtrr_fix_range_msr_set() in sync with mtrr_var_range_msr_set() in
this regard.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
There's no point in this being mapped UC by the guest due to using a
respective PAT index - set the ignore-PAT flag to true.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
- drop rsvd*_ prefixes from fields not really reserved anymore
- replace odd uses of <expr> ? 1 : 0
- drop pointless variables from ept_set_entry()
- streamline IOMMU mirroring code in ept_set_entry()
- don't open code is_epte_valid() (and properly use it when dumping)
- streamline entry cloning in ept_split_super_page()
- compact dumping code and output
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
CPUID[80000008].EAX[23:16] have been given the meaning of the guest
physical address restriction (in case it needs to be smaller than the
host's), hence we need to mirror that into vCPUID[80000008].EAX[7:0].
Enforce a lower limit at the same time, as well as a fixed value for
the virtual address bits, and zero for the guest physical address ones.
In order for the vMTRR code to see these overrides we need to make it
call hvm_cpuid() instead of domain_cpuid(), which in turn requires
special casing (and relaxing) the controlling domain.
This additionally should hide an ordering problem in the tools: Both
xend and xl appear to be restoring a guest from its image before
setting up the CPUID policy in the hypervisor, resulting in
domain_cpuid() returning all zeros and hence the check in
mtrr_var_range_msr_set() failing if the guest previously had more than
the minimum 36 physical address bits.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Just like previously done for some mem-op hypercalls, undo preemption
using the interface structures (altering it in ways the caller may not
expect) and replace it by storing the continuation point in the high
bits of sub-operation argument.
This also changes the "nr" fields of struct xen_hvm_track_dirty_vram
(operation already limited to 1Gb worth of pages) and struct
xen_hvm_modified_memory to be only 32 bits wide, consistent with those
of struct xen_set_mem{type,access}. If that's not acceptable for some
reason, we'd need to shrink the HVMOP_op_bits (while still enforcing
the [then higher] limit resulting from the need to be able to encode
the continuation).
Whether (and if so how) to adjust xc_hvm_track_dirty_vram(),
xc_hvm_modified_memory(), xc_hvm_set_mem_type(), and
xc_hvm_set_mem_access() to reflect the 32-bit restriction on "nr" is
unclear: If the APIs need to remain stable, all four functions should
probably check that there was no truncation. Preferably their
parameters would be changed to uint32_t or unsigned int, though.
As a minor cleanup, along with introducing the switch-wide "pfn" the
redundant "d" is also being converted to a switch-wide one.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
- boundary checks in HVMOP_modified_memory, HVMOP_set_mem_type, and
HVMOP_set_mem_access: all of these already check for overflow, so
there's no need to range check the first _and_ last PFN (checking
the last one suffices)
- copying back interface structures that were previously copied from
guest memory can use __copy_to_...(), since copy_from_...() already
did the address range validation
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Tim Deegan <tim@xen.org>
Attaching a CDROM device with 'xm scsi-attach domU /dev/sr0 0:0:0:0'
fails because for some reason the sr driver was not handled at all in
the match list. With the change the above command succeeds and the
device is attached.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Matt Wilson <msw@amazon.com>
The two assert in restore trigger sometimes after hundreds of
migrations. If they trigger the destination host will not destroy the
newly created, yet empty guest. After a second migration attempt to this
host there will be two guets with the same name and uuid. This situation
is poorly handled by the xm tools.
With this change the empty guest will be destroyed.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Matt Wilson <msw@amazon.com>
open a vhd file failed
For example:
[root@dom0_134_103 ~]# xm block-attach 0
tap2:tapdisk:vhd:/root/liyi***.vhd /dev/xvdz w
Error: ('create', '-avhd:/root/liyi***.vhd') failed (512 )
Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain]
Create a new virtual block device.
[root@dom0_134_103 ~]# xm block-attach 0
tap2:tapdisk:vhd:/root/liyi.vhd /dev/xvdz w
Error: The device "/dev/xvdz" is already defined
Usage: xm block-attach <Domain> <BackDev> <FrontDev> <Mode> [BackDomain]
Create a new virtual block device.
Signed-off-by: Yi Li <peteryili@tencent.com>
Acked-by: Matt Wilson <msw@amazon.com>
This function contains non-specific architecture code (mostly the tail of
xsm_multiboot_init). It will be used later to avoid code duplication.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Multiboot protocol is only used by x86. When XSM support for ARM will be
introduced, another way will be used to retrieve the policy blob.
Introduce CONFIG_MULTIBOOT to compile XSM specific multiboot code and
rename xsm_init into xsm_multiboot_init to avoid confusion.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Keir Fraser <keir@xen.org>
When the toolstack is setting vcpu state on behalf of a migrating guest, the
domain/vcpu reference from gdprintk() identifies the toolstack, not the
affected domain.
After this change, the error looks more like:
(XEN) d0 attempted to change d6v0's CR4 flags 00002660 -> 01876000
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
The list of function above are only used internally in common/sched_credit2.c
- migrate
- update_max_weight
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Clang 3.5 will fail to compile xen/common/sched_sedf.c because some function
are not used:
sched_sedf.c:141:20: error: unused function 'extraq_add_head' [-Werror,-Wunused-function]
static inline void extraq_add_head(struct vcpu *d, int i)
^
sched_sedf.c:147:20: error: unused function 'extraq_add_tail' [-Werror,-Wunused-function]
static inline void extraq_add_tail(struct vcpu *d, int i)
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
Processing up to 4G PFNs may take almost arbitrarily long, so
preemption is needed here.
This is XSA-89.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Tim Deegan <tim@xen.org>
When FLASK is the only enabled implementation of the XSM hooks in Xen,
some of the abstractions required to handle multiple XSM providers are
redundant and only produce unneeded overhead. This patch reduces the
memory overhead of enabling XSM on event channels by replacing the
untyped ssid pointer from struct evtchn with a union containing the
contents of the structure. This avoids an additional heap allocation
for every event channel, and on 64-bit systems, reduces the size of
struct evtchn by 4 bytes. If an out-of-tree XSM module needs the full
flexibility of the generic evtcnn ssid pointer, defining the symbol
XSM_NEED_GENERIC_EVTCHN_SSID will include a suitable pointer field.
This also cleans up the unused selinux_checkreqprot declaration left
from the Linux port.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Move the preprocessor definitions for all FLASK parameters other than
the enable flag off the compiler command line and into config.h, which
is the preferred location for such definitions.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
We can't just add in the hole shift value, as the hole may be at or
above the 44-bit boundary. Instead we need to determine the total bit
count until reaching 32 significant (not squashed out) bits in PFN
representations.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
A call to do_physdev_op with PHYSDEVOP_pirq_eoi_gmfn_v2/v1 will corrupt
struct hvm_domain when it writes to domain->arch.pv_domain.pirq_eoi_map.
Disallow that. Currently, such a path exists for linux dom0 pvh.
Signed-off-by: Mukesh Rathor <mukesh.rathor@oracle.com>
do_daemonize had open-coded handling of the results from xl_waitpid.
Instead, break out the meat of console_child_report into a new
function child_report (which returns an error code), and use it.
No functional change other than a change to the message printed if
forking the daemonic child fails.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
vncviewer_child_report was very similar to console_child_report.
We can abolish vncviewer_child_report by adding an xlchildnum
parameter to console_child_report.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
We record the descriptive string for the child in the children[]
array, and use it when reporting the exit status.
The only functional change is that the message reported for the
migration child is changed from "migration target process" to
"migration transport process".
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
GRUB usually always loads a whole disk track, even if that means going
beyond the end of the disk. We thus have to gracefully return an error,
instead of letting the blkfront go panic.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
typo in tools/configure.ac cause --enable-xenapi does not works
lead to variables XML2_CONFIG, CURL_CONFIG not set
Signed-off-by: Yixun Lan (dlan) <dennis.yxun@gmail.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The allocations for shared_irqs and pending_irqs are not checked and use
later. This may lead to a Xen segfault if the hypervisor run out of memory.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Fix compilation with clang 3.5:
/local/home/julien/works/arndale/xen/xen/include/asm/platforms/exynos5.h:1:9: error: '__ASM_ARM_PLATFORMS_EXYNOS5_H' is used as a header guard here, followed by #define of a different macro [-Werror,-Wheader-guard]
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/local/home/julien/works/arndale/xen/xen/include/asm/platforms/exynos5.h:2:9: note: '__ASM_ASM_PLATFORMS_EXYSNO5_H' is defined here; did you mean '__ASM_ARM_PLATFORMS_EXYNOS5_H'?
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__ASM_ARM_PLATFORMS_EXYNOS5_H
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On FreeBSD PTHREAD_STACK_MIN is 2048 by default, which is obviously
too low. Set the default back to the previous value (16 * 1024), or if
that's too low set it to PTHREAD_STACK_MIN.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@citrix.com>
nr_static_irqs and nr_irqs is defined in asm/irq.h (on both x86 and ARM).
Include directly the header in hooks.c to avoid compilation failure on ARM.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Rather than x86, on ARM XEN_GUEST_HANDLE and XEN_GUEST_HANDLE_PARAM are
not compatible. This will result to a compilation failure on ARM when XSM
will be enabled.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
On ARM, the compilation is failing with the following error:
In file included from flask_op.c:21:0:
./include/conditional.h:24:43: error: two or more data types in declaration specifiers
./include/conditional.h:25:42: error: two or more data types in declaration specifiers
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
The commit f7d29f7b "flask: add compat mode guest support" introduces
build breakage on ARM when XSM is enabled. It's because ARM doesn't use
compat mode.
flask_op.c:794:34: fatal error: compat/event_channel.h: No such file or directory
#include <compat/event_channel.h>
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
When the the module size is 0, it means that the module was not provided by
the user. It can happen, if the user choose to boot without initrd.
In this case, both fields (start and size) are zeroed. Therefore, next_module
will return 0 every time if there is other non-zero module after this one. This
can happen when the XSM module is added.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Flask code use %zu to print size_t variable. On ARM, size_t always defined
to unsigned long which make ARM build failed.
Fix it by using __SIZE_TYPE__.
Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Jan Beulich
Olaf Hering
Yi Li
Julien Grall
Andrew Cooper
Daniel De Graaf
Mukesh Rathor
Ian Jackson
Samuel Thibault
Yixun Lan (dlan)
Tim Deegan
Roger Pau Monne