- 05 Oct, 2018 4 commits
-
-
Paul Durrant authored
This patch modifies the declaration of the entry points to the IOMMU sub-system to use dfn_t and mfn_t in place of unsigned long. A subsequent patch will similarly modify the methods in the iommu_ops structure. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Roger Pau Monne <roger.pau@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Julien Grall <julien.grall@arm.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
-
Andrew Cooper authored
It is MASK_EXTR() in disguise, but less flexible. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Brian Woods <brian.woods@amd.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
-
Andrew Cooper authored
In practice, this allows the compiler to replace the loop with a pair of movs. No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Brian Woods <brian.woods@amd.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
-
Wei Liu authored
It is discovered that hvm_funcs made it into monitor.o even when HVM is disabled. This version of clang doesn't seem to completely eliminate the code after is_hvm_domain() in arch_monitor_get_capabilities(). Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com> Acked-by: Jan Beulich <jbeulich@suse.com>
-
- 04 Oct, 2018 14 commits
-
-
Andrew Cooper authored
This wrapper hides an opening and closing of the xenctrl handle, which amongst other things opens and closes multiple device files. A process should create one handle at the start of day and reuse that; indeed there is no guarentee that the process will retain sufficient permissions to re-open /dev/xen/privcmd at a later point. With the final user of Xenctrl.with_intf removed, drop the wrapper entirely. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
-
Andrew Cooper authored
Currently, an xc handle is opened in main() which is used for cleanup activities, and a new xc handle is temporarily opened every time a domain is introduced. This is inefficient, and amongst other things, requires full root privileges for the lifetime of oxenstored. All code using the Xenctrl handle is in domains.ml, so initialise xc as a global (now happens just before main() is called) and drop it as a parameter from Domains.create and Domains.cleanup. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
-
Andrew Cooper authored
No functional change. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Christian Lindig <christian.lindig@citrix.com>
-
Jan Beulich authored
Also make the iteration variable unsigned. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
Jan Beulich authored
Also specify field widths of the multiple similar lines printed in the course of the loop, to help readability. Make the iteration variable unsigned. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
Jan Beulich authored
The casts weren't even to the right type - all LAPIC registers are 32-bit (pairs/groups of registers may be combined to form larger logical ones, but this is not visible in the given data representation). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
Jan Beulich authored
Also avoid printing the MSR flags (they're always zero as of commit 2f1add6e "x86/vmx: Don't leak host syscall MSR state into HVM guests"), and print FPU registers only when the respective flag indicates the space holds valid data. Adjust format specifiers a little at the same time, in particular to avoid at least some leading zeros to be printed when the positions can't ever be non-zero. This helps readability in my opinion. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
Paul Durrant authored
...in intel_iommu_unmap_page(). This patch also includes some non-functional modifications in intel_iommu_map_page(). Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
-
Paul Durrant authored
...meaning 'device DMA frame number' i.e. a frame number mapped in the IOMMU (rather than the MMU) and hence used for DMA address translation. This patch is a largely cosmetic change that substitutes the terms 'gfn' and 'gaddr' for 'dfn' and 'daddr' in all the places where the frame number or address relate to a device rather than the CPU. The parts that are not purely cosmetic are: - the introduction of a type-safe declaration of dfn_t and definition of INVALID_DFN to make the substitution of gfn_x(INVALID_GFN) mechanical. - the introduction of __dfn_to_daddr and __daddr_to_dfn (and type-safe variants without the leading __) with some use of the former. Subsequent patches will convert code to make use of type-safe DFNs. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Julien Grall <julien.grall@arm.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
-
Jan Beulich authored
While commit 2a3b34ec ("x86/spec-ctrl: Yet more fixes for xpti= parsing") indeed fixed "xpti=dom0", it broke "xpti=no-dom0", in that this then became equivalent to "xpti=no". In particular, the presence of "xpti=" alone on the command line means nothing as to which default is to be overridden; "xpti=no-dom0", for example, ought to have no effect for DomU-s, as this is distinct from both "xpti=no-dom0,domu" and "xpti=no-dom0,no-domu". Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
-
Jan Beulich authored
Use separate tracking variables for the hardware domain and DomU-s. No functional change intended, but adjust the comment in init_speculation_mitigations() to match prior as well as resulting code. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
-
Jan Beulich authored
Use separate tracking variables for the hardware domain and DomU-s. No functional change intended. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
-
Juergen Gross authored
The per-cpu buffers for Xentrace are addressed by cpu-id, but the info array for the buffers is sized only by number of online cpus. This might lead to crashes when using Xentrace with smt=0. The t_info structure has to be sized based on nr_cpu_ids. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
-
Juergen Gross authored
Modify the xentrace utility to allow sparse cpu list resulting in not all possible cpus having a trace buffer allocated. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: George Dunlap <george.dunlap@citrix.com>
-
- 03 Oct, 2018 3 commits
-
-
Julien Grall authored
Currently, the toolstack is considering Arm guest always PV. However, they are very similar to PVH because HW virtualization extension are used and QEMU is not started. So switch Arm guest type to PVH. To keep compatibility with toolstack creating Arm guest with PV type (e.g libvirt), libxl will now convert those guests to PVH. Furthermore, the default type for Arm in xl will now be PVH to allow smooth transition for user. Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
Julien Grall authored
The PV fields kernel, ramdisk, cmdline are only there for compatibility with old toolstack. Instead of manually copying them over to there new field, use the deprecated_by attribute in the IDL. Suggested-by: Roger Pau Monné <roger.pau@citrix.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
Julien Grall authored
libxl__arch_domain_build_info_setdefault A follow-up will require to modify default of multiple fields of build_info. So rename the function accordingly. No functional change. Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
- 02 Oct, 2018 4 commits
-
-
Julien Grall authored
At the moment, Xen is assuming the hardware domain will have the same number of re-distributor regions as the host. However, as the number of CPUs or the stride (e.g on GICv4) may be different we end up exposing regions which does not contain any re-distributors. When booting, Linux will go through all the re-distributor region to check whether a property (e.g vPLIs) is available accross all the re-distributors. This will result to a data abort on empty regions because there are no underlying re-distributor. So we need to limit the number of regions exposed to the hardware domain. The code reworked to only expose the minimun number of regions required by the hardware domain. It is assumed the regions will be populated starting from the first one. Lastly, rename vgic_v3_rdist_count to reflect the value return by the helper. Reported-by: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
Julien Grall authored
A follow-up patch will require to know the number of vCPUs when initializating the vGICv3 domain structure. However this information is not available at domain creation. This is only known once XEN_DOMCTL_max_vpus is called for that domain. In order to get the max vCPUs around, delay the domain part of the vGIC v3 initialization until the first vCPU of the domain is initialized. Signed-off-by: Julien Grall <julien.grall@arm.com> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Acked-but-disliked-by: Stefano Stabellini <sstabellini@kernel.org>
-
Roger Pau Monné authored
And just rely on arch_iommu_hwdom_init to setup the correct inclusive mappings as it's done for Intel. AMD has code in amd_iommu_hwdom_init to setup inclusive mappings up to max_pdx, remove this since it's now a duplication of arch_iommu_hwdom_init. Note that AMD mapped every page with a valid mfn up to max_pdx, arch_iommu_hwdom_init will only do so for memory below 4GB, so this is a functional change for AMD. Move the default setting of iommu_hwdom_{inclusive/reserved} to arch_iommu_hwdom_init since the defaults are now the same for both Intel and AMD. Reported-by: Paul Durrant <paul.durrant@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Acked-by: Suravee Suthikulpanit <suravee.suthikupanit@amd.com>
-
Roger Pau Monné authored
iommu_hwdom_inclusive was used where iommu_hwdom_reserved should be used. Reported-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
-
- 01 Oct, 2018 11 commits
-
-
Julien Grall authored
call_smc is a subset of arm_smccc_smc. Rather than having 2 methods to do SMCCC call, replace all call to the former by the later. Signed-off-by: Julien Grall <julien.grall@arm.com> [PSCI_RET(res.a0)/PSCI_RET(res)] Signed-off-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
Julien Grall authored
Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com>
-
Julien Grall authored
Some capababilities are set right during boot and will never change afterwards. At the moment, the function cpu_have_caps will check whether the cap is enabled from the memory. It is possible to avoid the load from the memory by using an ALTERNATIVE. With that the check is just reduced to 1 instruction. Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
Volodymyr Babchuk authored
Existing SMC wrapper call_smc() allows only 4 parameters and returns only one value. This is enough for existing use in PSCI code, but TEE mediator will need a call that is fully compatible with ARM SMCCC v1.0. This patch adds a wrapper for both arm32 and arm64. In the case of arm32, the wrapper is just an alias to the ARM SMCCC v1.1 as the convention is the same. CC: "Edgar E. Iglesias" <edgar.iglesias@xilinx.com> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> [julien: Rework the wrapper to make it closer to SMCC 1.1 wrapper] Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
George Dunlap authored
The migration code reads scheduler parameters on the sending side and tries to set them again on the receiving side, failing if this fails; the result is that a simple upgrade from 4.11 -> 4.12 will now fail all migrations. Solving this is not simple; revert the credit2 upgrade until we can sort something out. This reverts commit ec666244 . Signed-off-by: George Dunlap <george.dunlap@citrix.com>
-
Andrew Cooper authored
This allows all system domids to be printed by name, rather than special casing the idle vcpus alone. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
-
Marc Zyngier authored
If someone has the silly idea to write something along those lines: extern u64 foo(void); void bar(struct arm_smccc_res *res) { arm_smccc_1_1_smc(0xbad, foo(), res); } they are in for a surprise, as this gets compiled as: 0000000000000588 <bar>: 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 <foo> 5a4: aa0003e1 mov x1, x0 5a8: d4000003 smc #0x0 5ac: b4000073 cbz x19, 5b8 <bar+0x30> 5b0: a9000660 stp x0, x1, [x19] 5b4: a9010e62 stp x2, x3, [x19, #16] 5b8: f9400bf3 ldr x19, [sp, #16] 5bc: a8c27bfd ldp x29, x30, [sp], #32 5c0: d65f03c0 ret 5c4: d503201f nop The call to foo "overwrites" the x0 register for the return value, and we end up calling the wrong secure service. A solution is to evaluate all the parameters before assigning anything to specific registers, leading to the expected result: 0000000000000588 <bar>: 588: a9be7bfd stp x29, x30, [sp, #-32]! 58c: 910003fd mov x29, sp 590: f9000bf3 str x19, [sp, #16] 594: aa0003f3 mov x19, x0 598: aa1e03e0 mov x0, x30 59c: 94000000 bl 0 <_mcount> 5a0: 94000000 bl 0 <foo> 5a4: aa0003e1 mov x1, x0 5a8: d28175a0 mov x0, #0xbad 5ac: d4000003 smc #0x0 5b0: b4000073 cbz x19, 5bc <bar+0x34> 5b4: a9000660 stp x0, x1, [x19] 5b8: a9010e62 stp x2, x3, [x19, #16] 5bc: f9400bf3 ldr x19, [sp, #16] 5c0: a8c27bfd ldp x29, x30, [sp], #32 5c4: d65f03c0 ret Reported-by: Stefano Stabellini <stefanos@xilinx.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
Marc Zyngier authored
An unfortunate consequence of having a strong typing for the input values to the SMC call is that it also affects the type of the return values, limiting r0 to 32 bits and r{1,2,3} to whatever was passed as an input. Let's turn everything into "unsigned long", which satisfies the requirements of both architectures, and allows for the full range of return values. Reported-by: Stefano Stabellini <stefanos@xilinx.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Volodymyr Babchuk <volodymyr_babchuk@epam.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
Julien Grall authored
vgic_v3_its_free_domain may be called before vgic_v3_its_init_domain if the vGIC was failing to initalize itself. This means the list would be unitialized and result in a crash. Thankfully, we only allow ITS for the hardware domain. So the crash is not a security issue. Fix it by checking whether the list the NULL. Signed-off-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
-
Wei Liu authored
This helps capture issues before console is initialised. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
-
Wei Liu authored
The relocation code in __start_xen requires one extra element in the module array. By the looks of it the temporary array is already large enough. Panic if that's not the case. While at it, turn an ASSERT to panic() as well. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
-
- 28 Sep, 2018 4 commits
-
-
Wei Liu authored
Requested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
-
Wei Liu authored
BOOTSTRAP_DIRECTMAP_END is gone. The comment in question should refer to BOOSTRAP_MAP_BASE and 4GB instead. Move the entire comment block to where it belongs -- immediately before the loop which does the things said in the comment. Remove two trailing spaces while at it. Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com>
-
Andrew Cooper authored
VERS_1.2 can't extend itself. It should extend VERS_1.1 Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-
Andrew Cooper authored
Xen 4.11 shipped with a SONAME of 1.1. For staging (and 4.12 eventually), the SONAME was bumped to 1.2 by c/s 28ca696a . Further changes before 4.12 ships should not bump the SONAME. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
-