summaryrefslogtreecommitdiff
path: root/docs
Commit message (Collapse)AuthorAgeFilesLines
* docs/man: fix xenstore-write synopsisYann Dirson2023-05-091-1/+1
| | | | | | Reported-by: zithro <slack@rabbit.lu> Signed-off-by: Yann Dirson <yann.dirson@vates.fr> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
* acpi: add TPM2 interface definitionJennifer Herbert2023-05-081-1/+2
| | | | | | | | | This patch introduces an optional TPM 2 interface definition to the ACPI table, which is to be used as part of a vTPM 2 implementation. Signed-off-by: Jennifer Herbert <jennifer.herbert@citrix.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
* acpi: make TPM version configurableJennifer Herbert2023-05-081-0/+9
| | | | | | | | | | | This patch makes the TPM version, for which the ACPI library probes, configurable. If acpi_config.tpm_verison is set to 1, it indicates that 1.2 (TCPA) should be probed. I have also added to hvmloader an option to allow setting this new config, which can be triggered by setting the platform/tpm_verion xenstore key. Signed-off-by: Jennifer Herbert <jennifer.herbert@citrix.com> Reviewed-by: Jason Andryuk <jandryuk@gmail.com> Acked-by: Jan Beulich <jbeulich@suse.com>
* docs: allow generic virtio device types to contain device-idViresh Kumar2023-05-031-2/+5
| | | | | | | | | | | | | | | | | For generic virtio devices, where we don't need to add compatible or other special DT properties, the type field is set to "virtio,device". But this misses the case where the user sets the type with a valid virtio device id as well, like "virtio,device1a" for file system device. The complete list of virtio device ids is mentioned here: https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-2160005 Update documentation to support that as well. Fixes: dd54ea500be8 ("docs: add documentation for generic virtio devices") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
* build: Use HTTPS for all xenbits.xen.org Git reposDemi Marie Obenour2023-03-242-2/+2
| | | | | | | | | | | | | | | | | Obtaining code over an insecure transport is a terrible idea for blatently obvious reasons. Even for non-executable data, insecure transports are considered deprecated. This patch enforces the use of secure transports for all xenbits git repositories. It was generated with the following shell script: git ls-files -z | xargs -0 -- sed -Ei -- 's@(git://xenbits\.xen\.org|http://xenbits\.xen\.org/git-http)/@https://xenbits.xen.org/git-http/@g' All altered links have been tested and are known to work. Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* xen/grants: repurpose command line max optionsRoger Pau Monne2023-03-151-7/+9
| | | | | | | | | | | | | | | | | | | | | | Slightly change the meaning of the command line gnttab_max_{maptrack_,}frames: do not use them as upper bounds for the passed values at domain creation, instead just use them as defaults in the absence of any provided value. It's not very useful for the options to be used both as defaults and as capping values for domain creation inputs. The defaults passed on the command line are used by dom0 which has a very different grant requirements than a regular domU. dom0 usually needs a bigger maptrack array, while domU usually require a bigger number of grant frames. The relaxation in the logic for the maximum size of the grant and maptrack table sizes doesn't change the fact that domain creation hypercall can cause resource exhausting, so disaggregated setups should take it into account. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
* xl/libxl: Add OEM string support to smbiosJason Andryuk2023-03-151-0/+4
| | | | | | | | | | | Add support for OEM strings in the SMBIOS type 11. hvmloader checks them sequentially, so hide the implementation detail. Allow multiple plain oem= items and assign the numeric values internally. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
* xl/libxl: Add ability to specify SMBIOS stringsJason Andryuk2023-03-151-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | hvm_xs_strings.h specifies xenstore entries which can be used to set or override smbios strings. hvmloader has support for reading them, but xl/libxl support is not wired up. Allow specifying the strings with the new xl.cfg option: smbios=["bios_vendor=Xen Project","system_version=1.0"] In terms of strings, the SMBIOS specification 3.5 says: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.5.0.pdf """ Strings must be encoded as UTF-8 with no byte order mark (BOM). For compatibility with older SMBIOS parsers, US-ASCII characters should be used. NOTE There is no limit on the length of each individual text string. However, the length of the entire structure table (including all strings) must be reported in the Structure Table Length field of the 32-bit Structure Table Entry Point (see 5.2.1) and/or the Structure Table Maximum Size field of the 64-bit Structure Table Entry Point (see 5.2.2). """ The strings aren't checked for utf-8 or length. hvmloader has a sanity check on the overall length. The libxl_smbios_type enum starts at 1 since otherwise the 0th key is not printed in the json output. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
* flask/label-pci: Allow specifying optional irq labelJason Andryuk2023-03-141-0/+16
| | | | | | | | | | | | | | | IRQs can be shared between devices, so using the same label as the PCI device can create conflicts where the IRQ is labeled with one of the device labels preventing assignment of the second device to the second domain. Add the ability to specify an irq label distinct from the PCI device, so a shared irq label can be specified. The policy would then be written such that the two domains can each use the shared IRQ type in addition to their labeled PCI device. That way we can still label most of the PCI device resources and assign devices in the face of shared IRQs. Signed-off-by: Jason Andryuk <jandryuk@gmail.com> Reviewed-by: Daniel P. Smith <dpsmith@apertussolutions.com>
* misra: add entries to exclude-list.jsonLuca Fancellu2023-03-061-1/+198
| | | | | | | | | Add entries to the exclude-list.json for those files that need to be excluded from the analysis scan. Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* cppcheck: add a way to exclude files from the scanLuca Fancellu2023-03-062-0/+50
| | | | | | | | | | | | | | | | | | | | | Add a way to exclude files from the scan, in this way we can skip some findings from the report on those files that Xen doesn't own. To do that, introduce the exclude-list.json file under docs/misra, this file will be populated with relative path to the files/folder to be excluded. Introduce a new module, exclusion_file_list.py, to deal with the exclusion list file and use the new module in cppcheck_analysis.py to take a list of excluded paths to update the suppression list of cppcheck. Modified --suppress flag for cppcheck tool to remove unmatchedSuppression findings for those external file that are listed but for example not built for the current architecture. Add documentation for the file. Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* docs/process: branching-checklist: Add a list of accounts at the beginningJulien Grall2023-02-191-0/+8
| | | | | | | | | | | | | | The checklist requires to have access to several accounts on both xenbits and osstest. List those accounts at the beginning of the file so it is easier to check if one has the permissions before starting the branching process. Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> ---- Changes in v2: - Add Henry's reviewed-by
* docs/proces: branching-checklist: Update the section "add to patchbot"Julien Grall2023-02-191-1/+1
| | | | | | | | | | | | | Make clear the patchbot is accessible from the user "xen" on xenbits. Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: George Dunlap <george.dunlap@citrix.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> ---- Changes in v2: - Add Henry's reviewed-by - Add George's acked-by
* docs/process: branching-checklist: Remove section about the cambridge coloJulien Grall2023-02-191-6/+0
| | | | | | | | | | | | | | | | The cambridge colo was internal to Citrix (now Cloud) and hasn't been used by the community for a while. So remove the section. Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: George Dunlap <george.dunlap@cloud.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> ---- Changes in v2: - Add George's acked-by - Add Henry's reviewed-by
* docs/process: branching-checklist: Reword the section about Config.mkJulien Grall2023-02-191-5/+6
| | | | | | | | | | | | | Since at least Xen 4.12, the revision for external trees don't contain the word "unstable". So explicitly list the *_REVISION variables that need to be updated as part of the branching process. Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com> ---- Changes in v2: * Explain what should be the tag format for each variables
* credit2: respect credit2_runqueue=all when arranging runqueuesMarek Marczykowski-Górecki2023-02-151-0/+5
| | | | | | | | | | | | | | | Documentation for credit2_runqueue=all says it should create one queue for all pCPUs on the host. But since introduction sched_credit2_max_cpus_runqueue, it actually created separate runqueue per socket, even if the CPUs count is below sched_credit2_max_cpus_runqueue. Adjust the condition to skip syblink check in case of credit2_runqueue=all. Fixes: 8e2aa76dc167 ("xen: credit2: limit the max number of CPUs in a runqueue") Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Juergen Gross <jgross@suse.com>
* x86/spec-ctrl: Mitigate Cross-Thread Return Address PredictionsAndrew Cooper2023-02-141-1/+1
| | | | | | | This is XSA-426 / CVE-2022-27672 Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
* x86/shskt: Disable CET-SS on parts susceptible to fractured updatesAndrew Cooper2023-02-091-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refer to Intel SDM Rev 70 (Dec 2022), Vol3 17.2.3 "Supervisor Shadow Stack Token". Architecturally, an event delivery which starts in CPL<3 and switches shadow stack will first validate the Supervisor Shadow Stack Token (setting the busy bit), then pushes CS/LIP/SSP. One example of this is an NMI interrupting Xen. Some CPUs suffer from an issue called fracturing, whereby a fault/vmexit/etc between setting the busy bit and completing the event injection renders the action non-restartable, because when it comes time to restart, the busy bit is found to be already set. This is far more easily encountered under virt, yet it is not the fault of the hypervisor, nor the fault of the guest kernel. The fault lies somewhere between the architectural specification, and the uarch behaviour. Intel have allocated CPUID.7[1].ecx[18] CET_SSS to enumerate that supervisor shadow stacks are safe to use. Because of how Xen lays out its shadow stacks, fracturing is not expected to be a problem on native. Detect this case on boot and default to not using shstk if virtualised. Specifying `cet=shstk` on the command line will override this heuristic and enable shadow stacks irrespective. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
* docs: clarify xenstore permission documentationJuergen Gross2023-02-091-7/+10
| | | | | | | | | | | | | | | | | | In docs/misc/xenstore.txt the description of the Xenstore node access permissions is missing one important aspect, which can be found only in the code or in the wiki [1]: The first permission entry is defining the owner of the node via the domid, and the access rights for all domains NOT having a dedicated permission entry. Make that aspect clear in the official documentation. [1]: https://wiki.xenproject.org/wiki/XenBus#Permissions Reported-by: Edwin Török <edwin.torok@cloud.com> Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
* docs/process: branching-checklist: Clarify steps to add the branch in osstestJulien Grall2023-02-091-1/+3
| | | | | | | | | | | The steps to add the new branch in osstest doesn't mention the change should be committed. Update the steps to clarify that. Take the opportunity to switch to use $v instead hardcoded version. Signed-off-by: Julien Grall <jgrall@amazon.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
* docs/process: branching-checklist: Remove reference to rootJulien Grall2023-02-091-2/+1
| | | | | | | | | | | | The steps to generate the documentation for the new branch requires to ssh as root and then su to run with the user xendocs. The release technician may not (and should not) have access to root. So update the step to directly ssh as xendocs. Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: George Dunlap <george.dunlap@cloud.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
* docs/process: branching-checklist: Remove reference to qemu-ijw.gitJulien Grall2023-02-091-3/+0
| | | | | | | | | | | | | | | Per [1], qemu-iwj.git was a clone of QEMU traditional on Ian's computer for tagging QEMU trad. The next section will provide tag for the official tree. So remove the section about qemu-ijw.git. [1] 25482.10006.140155.984629@chiark.greenend.org.uk Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: George Dunlap <george.dunlap@cloud.com> Acked-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
* docs/process: branching-checklist: Use consistent indentationJulien Grall2023-02-091-51/+51
| | | | | | | | | | | | | At the moment, branch-checklist.txt is using a mix of soft and hard tab. They are both meant to be represented using 8 characters. In Xen we tend to use 4-space softtab represented with 4 characters. So to avoid having to use a different editor configuration, switch all the indentation to 4-space softtab. Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: George Dunlap <george.dunlap@cloud.com> Reviewed-by: Henry Wang <Henry.Wang@arm.com>
* xen/arm: Add support for booting gzip compressed uImagesMichal Orzel2023-02-081-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment, Xen does not support booting gzip compressed uImages. This is because we are trying to decompress the kernel before probing the u-boot header. This leads to a failure as the header always appears at the top of the image (and therefore obscuring the gzip header). Move the call to kernel_uimage_probe before kernel_decompress and make the function self-containing by taking the following actions: - take a pointer to struct bootmodule as a parameter, - check the comp field of a u-boot header to determine compression type, - in case of compressed image, call kernel_decompress passing uImage header size as an offset to gzip header, - set up zimage.{kernel_addr,len} accordingly, - return -ENOENT in case of a u-boot header not found to distinguish it amongst other return values and make it the only case for falling through to try to probe other image types. Modify kernel_decompress to take an additional parameter being an offset to a gzip header from start address. This is needed so that a function can first operate on a region containing actually compressed kernel (in case of compressed uImage, size of u-boot header is an offset to a gzip header) and then at the end pass the entire region (as it was before taking an offset into account) to fw_unreserved_regions for freeing. This approach avoids splitting the uImage probing into 2 stages (executed before and after decompression) which otherwise would be necessary to properly parse header, update boot module start and size before decompression and update zimage.{kernel_addr,len} afterwards. Remove the limitation from the booting.txt documentation. Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewwed-by: Julien Grall <jgrall@amazon.com>
* xen/public: move xenstore related doc into 9pfs.hJuergen Gross2023-02-061-149/+4
| | | | | | | | | | | | | | | | | | | | | | | The Xenstore related documentation is currently to be found in docs/misc/9pfs.pandoc, instead of the related header file xen/include/public/io/9pfs.h like for most other paravirtualized device protocols. There is a comment in the header pointing at the document, but the given file name is wrong. Additionally such headers are meant to be copied into consuming projects (Linux kernel, qemu, etc.), so pointing at a doc file in the Xen git repository isn't really helpful for the consumers of the header. This situation is far from ideal, which is already being proved by the fact that neither qemu nor the Linux kernel are implementing the device attach/detach protocol correctly. Change that by moving the Xenstore related 9pfs documentation from docs/misc/9pfs.pandoc into xen/include/public/io/9pfs.h. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
* Add more rules to docs/misra/rules.rstStefano Stabellini2023-02-021-0/+20
| | | | | | | | | | | As agreed during the last MISRA C discussion, I am adding the following MISRA C rules: 7.1, 7.3, 18.3. I am also adding 13.1 that was "agreed pending an analysis on the amount of violations". There are zero violations reported by cppcheck. Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com>
* xen/arm: Probe the load/entry point address of an uImage correctlyAyan Kumar Halder2023-01-301-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, kernel_uimage_probe() does not read the load/entry point address set in the uImge header. Thus, info->zimage.start is 0 (default value). This causes, kernel_zimage_place() to treat the binary (contained within uImage) as position independent executable. Thus, it loads it at an incorrect address. The correct approach would be to read "uimage.load" and set info->zimage.start. This will ensure that the binary is loaded at the correct address. Also, read "uimage.ep" and set info->entry (ie kernel entry address). If user provides load address (ie "uimage.load") as 0x0, then the image is treated as position independent executable. Xen can load such an image at any address it considers appropriate. A position independent executable cannot have a fixed entry point address. This behavior is applicable for both arm32 and arm64 platforms. Earlier for arm32 and arm64 platforms, Xen was ignoring the load and entry point address set in the uImage header. With this commit, Xen will use them. This makes the behavior of Xen consistent with uboot for uimage headers. Users who want to use Xen with statically partitioned domains, can provide non zero load address and entry address for the dom0/domU kernel. It is required that the load and entry address provided must be within the memory region allocated by Xen. A deviation from uboot behaviour is that we consider load address == 0x0, to denote that the image supports position independent execution. This is to make the behavior consistent across uImage and zImage. Signed-off-by: Ayan Kumar Halder <ayan.kumar.halder@amd.com> [stefano: minor doc improvement] Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* tools/xenstore: introduce trace classesJuergen Gross2023-01-201-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Make the xenstored internal trace configurable by adding classes which can be switched on and off independently from each other. Define the following classes: - obj: Creation and deletion of interesting "objects" (watch, transaction, connection) - io: incoming requests and outgoing responses - wrl: write limiting Per default "obj" and "io" are switched on. Entries written via trace() will always be printed (if tracing is on at all). Add the capability to control the trace settings via the "log" command and via a new "--log-control" command line option. Add a missing trace_create() call for creating a transaction. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
* xen/arm: Allow to set grant table related limits for dom0less domUsMichal Orzel2022-12-211-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment, for dom0less domUs, we do not have a way to specify per domain grant table related limits (unlike when using xl), namely max version, max number of grant frames, max number of maptrack frames. This means that such domains always use the values specified by the Xen command line parameters or their default values if unspecified. In order to have more control over dom0less domUs, introduce the following device-tree properties that can be set under domUs nodes: - max_grant_version to set the maximum grant table version the domain is allowed to use, - max_grant_frames to set the maximum number of grant frames the domain is allowed to have, - max_maptrack_frames to set the maximum number of grant maptrack frames the domain is allowed to have. Update documentation accordingly. Note that the values obtained from device tree are of type uint32_t, whereas the d_cfg.max_{grant_frames,maptrack_frames} are of type int32_t. Call panic in case of overflow. Other sanity checks are already there in grant_table_init() resulting in panic in case of errors, therefore no need to repeat them in create_domUs(). Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* x86/vmx: implement Notify VM ExitRoger Pau Monné2022-12-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under certain conditions guests can get the CPU stuck in an unbounded loop without the possibility of an interrupt window to occur on instruction boundary. This was the case with the scenarios described in XSA-156. Make use of the Notify VM Exit mechanism, that will trigger a VM Exit if no interrupt window occurs for a specified amount of time. Note that using the Notify VM Exit avoids having to trap #AC and #DB exceptions, as Xen is guaranteed to get a VM Exit even if the guest puts the CPU in a loop without an interrupt window, as such disable the intercepts if the feature is available and enabled. Setting the notify VM exit window to 0 is safe because there's a threshold added by the hardware in order to have a sane window value. Note the handling of EXIT_REASON_NOTIFY in the nested virtualization case is passed to L0, and hence a nested guest being able to trigger a notify VM exit with an invalid context would be able to crash the L1 hypervisor (by L0 destroying the domain). Since we don't expose VM Notify support to L1 it should already enable the required protections in order to prevent VM Notify from triggering in the first place. Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
* docs: add documentation for generic virtio devicesViresh Kumar2022-12-141-0/+33
| | | | | | | | | This patch updates xl.cfg man page with details of generic Virtio device related information. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
* xen: Justify linker script defined symbols in include/xen/kernel.hLuca Fancellu2022-12-121-0/+9
| | | | | | | | | | | | | | Eclair and Coverity found violation of the MISRA rule 8.6 for the symbols _start, _end, start, _stext, _etext, _srodata, _erodata, _sinittext, _einittext which are declared in xen/include/xen/kernel.h. All those symbols are defined by the liker script so we can deviate from the rule 8.6 for these cases. Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Acked-by: Jan Beulich <jbeulich@suse.com> Tested-by: Stefano Stabellini <sstabellini@kernel.org>
* xen/scripts: add cppcheck tool to the xen-analysis.py scriptLuca Fancellu2022-12-124-30/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add Cppcheck analysis to the xen-analysis.py script using the arguments --run-cppcheck. Now cppcheck analysis will build Xen while the analysis is performed on the source files, it will produce a text report and an additional html output when the script is called with --cppcheck-html. With this patch cppcheck will benefit of platform configuration files that will help it to understand the target of the compilation and improve the analysis. These are XML files placed in xen/tools/cppcheck-plat/, describing to cppcheck the length of basic types to help it in the analysis. To do so: - Update xen-analysis.py with the code to integrate cppcheck. - add platform configuration files for cppcheck.. - add cppcheck-cc.sh script that is a wrapper for cppcheck and it's used as Xen compiler, it will intercept all flags given from the make build system and it will execute cppcheck on the compiled file together with the file compilation. - guarded hypercall-defs.c with CPPCHECK define because cppcheck gets confused as the file does not contain c code. - add false-positive-cppcheck.json file - update documentation. - update .gitignore Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Stefano Stabellini <sstabellini@kernel.org>
* xen/scripts: add xen-analysis.py for coverity and eclair analysisLuca Fancellu2022-12-125-0/+280
| | | | | | | | | | | | | | | | | | | | | | | | Add new script for coverity/eclair analysis tool that will enable the procedure to suppress findings when these tool are used. The procedure is documented in docs/misra/documenting-violations.rst and the script is documented in docs/misra/xen-static-analysis.rst. Add in docs/misra/ the files safe.json and false-positive-{coverity,eclair}.json that are JSON files containing the data structures for the justifications, they are used by the analysis script to link the Xen tags to the proprietary tool comment. Add docs/misra/documenting-violations.rst to explain how to add justifications. Add docs/misra/xen-static-analysis.rst to explain how to use the script to analyse Xen. Add analysis artifacts files to .gitignore. Signed-off-by: Luca Fancellu <luca.fancellu@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> Tested-by: Stefano Stabellini <sstabellini@kernel.org>
* docs: do not install .deps filesMarek Marczykowski-Górecki2022-12-121-0/+1
| | | | | | | | It isn't really part of the documentation. Furthermore, entries there are in not determined order, which breaks build reproducibility. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* process/release-technician-checklist: Explain how the banner in README is ↵Julien Grall2022-12-051-1/+5
| | | | | | | | | | generated Explain how the banner in README is generated and take the opportunity to mention what it should look like for RC. Signed-off-by: Julien Grall <jgrall@amazon.com> Acked-by: Jan Beulich <jbeulich@suse.com>
* xen/locks: add dynamic lock recursion checksJuergen Gross2022-12-021-0/+12
| | | | | | | | | | | | | | | | | | Add checking of lock recursion to the hypervisor. This is done by using a percpu data array for storing the address of each taken lock. Any attempt to take a lock twice (with the exception of recursive spinlocks) will result in a crash. This is especially meant for detecting attempts to take a rwlock multiple times as a reader, which will only result in a deadlock in case of another cpu trying to get the lock as a writer in between. The additional checks are not performance neutral, so they are enabled only in debug builds per default, as the checks are active only with CONFIG_DEBUG_LOCKS enabled. The size of the percpu data array can be selected via a boot parameter. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
* Introduce more MISRA C rules to docs/misra/rules.rstStefano Stabellini2022-12-011-0/+36
| | | | | | | | | | | | Add the new MISRA C rules agreed by the MISRA C working group to docs/misra/rules.rst. Add a comment for Rule 19.1 to explain that Eclair's findings are "caution" reports, not violations. Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com> Acked-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
* Set version to 4.18; return ./autogen.shJulien Grall2022-12-011-9/+9
| | | | Signed-off-by: Julien Grall <jgrall@amazon.com>
* docs/misc/arm: Update references to Linux kernel docsMichal Orzel2022-12-012-8/+8
| | | | | | | | | Some time ago, Linux switched the format of docs to ReST and the format of device-tree bindings to json-schema. Signed-off-by: Michal Orzel <michal.orzel@amd.com> Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com> Release-acked-by: Henry Wang <Henry.Wang@arm.com>
* x86/hvm: Revert per-domain APIC acceleration supportAndrew Cooper2022-11-172-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was really hoping to avoid this, but its now too late in the 4.17 freeze and we still don't have working fixes. The in-Xen calculations for assistance capabilities are buggy. For the avoidance of doubt, the original intention was to be able to control every aspect of a APIC acceleration so we could comprehensively test Xen's support, as it has proved to be buggy time and time again. Even after a protracted discussion on what the new API ought to mean, attempts to apply it to the existing logic have been unsuccessful, proving that the API/ABI is too complicated for most people to reason about. This reverts most of: 2ce11ce249a3981bac50914c6a90f681ad7a4222 6b2b9b3405092c3ad38d7342988a584b8efa674c leaving in place the non-APIC specific changes (minimal as they are). This takes us back to the behaviour of Xen 4.16 where APIC acceleration is configured on a per system basis. This work will be revisted in due course. Fixes: 2ce11ce249a3 ("x86/HVM: allow per-domain usage of hardware virtualized APIC") Fixes: 6b2b9b340509 ("x86: report Interrupt Controller Virtualization capabilities") Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Release-acked-by: Henry Wang <Henry.Wang@arm.com>
* amd/virt_ssbd: set SSBD at vCPU context switchRoger Pau Monne2022-11-161-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes an issue with running C code in a GIF=0 region, that's problematic when using UBSAN or other instrumentation techniques. The current logic for AMD SSBD context switches it on every vm{entry,exit} if the Xen and guest selections don't match. This is expensive when not using SPEC_CTRL, and hence should be avoided as much as possible. When SSBD is not being set from SPEC_CTRL on AMD don't context switch at vm{entry,exit} and instead only context switch SSBD when switching vCPUs. This has the side effect of running Xen code with the guest selection of SSBD, the documentation is updated to note this behavior. Also note that then when `ssbd` is selected on the command line guest SSBD selection will not have an effect, and the hypervisor will run with SSBD unconditionally enabled when not using SPEC_CTRL itself. As a result of no longer running the code to set SSBD in a GIF=0 region the locking of amd_set_legacy_ssbd() can be done using normal spinlocks, and some more checks can be added to assure it works as intended. Finally it's also worth noticing that since the guest SSBD selection is no longer set on vmentry the VIRT_SPEC_MSR handling needs to propagate the value to the hardware as part of handling the wrmsr. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Extend the msrs->virt_spec_ctrl context switching comment. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
* tools/xenstore: remove XEN_LIB_STORED and XENSTORED_ROOTDIRJuergen Gross2022-11-021-4/+0
| | | | | | | | | | | | | | | | | XEN_LIB_STORED is serving no real purpose, as it is a mount point for a tmpfs, so it can be replaced easily by XEN_RUN_STORED. XENSTORED_ROOTDIR is basically unused already, there is just a single reference in xs_daemon_rootdir() with a fallback to XEN_LIB_STORED, and a .gdbinit file setting it. Remove the .gdbinit file, as it is not known having been used since ages, and make xs_daemon_rootdir() an alias of xs_daemon_rundir(). Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Juergen Gross <jgross@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> Release-acked-by: Henry Wang <Henry.Wang@arm.com>
* docs: enhance xenstore.txt with permissions descriptionJuergen Gross2022-11-011-0/+11
| | | | | | | | | | | | | | | The permission scheme of Xenstore nodes is not really covered by docs/misc/xenstore.txt, other than referring to the Xen wiki. Add a paragraph explaining the permissions of nodes, and especially mentioning removal of nodes when a domain has been removed from Xenstore. This is part of XSA-419. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Edwin Török <edvin.torok@citrix.com> Acked-by: Julien Grall <jgrall@amazon.com>
* tools/xenstore: add control command for setting and showing quotaJuergen Gross2022-11-011-0/+11
| | | | | | | | | | | | | | | | | | | Add a xenstore-control command "quota" to: - show current quota settings - change quota settings - show current quota related values of a domain Note that in the case the new quota is lower than existing one, Xenstored may continue to handle requests from a domain exceeding the new limit (depends on which one has been broken) and the amount of resource used will not change. However the domain will not be able to create more resource (associated to the quota) until it is back to below the limit. This is part of XSA-326. Signed-off-by: Juergen Gross <jgross@suse.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
* x86/mwait-idle: add 'preferred-cstates' command line optionArtem Bityutskiy2022-10-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Sapphire Rapids Xeon (SPR) the C1 and C1E states are basically mutually exclusive - only one of them can be enabled. By default, 'intel_idle' driver enables C1 and disables C1E. However, some users prefer to use C1E instead of C1, because it saves more energy. This patch adds a new module parameter ('preferred_cstates') for enabling C1E and disabling C1. Here is the idea behind it. 1. This option has effect only for "mutually exclusive" C-states like C1 and C1E on SPR. 2. It does not have any effect on independent C-states, which do not require other C-states to be disabled (most states on most platforms as of today). 3. For mutually exclusive C-states, the 'intel_idle' driver always has a reasonable default, such as enabling C1 on SPR by default. On other platforms, the default may be different. 4. Users can override the default using the 'preferred_cstates' parameter. 5. The parameter accepts the preferred C-states bit-mask, similarly to the existing 'states_off' parameter. 6. This parameter is not limited to C1/C1E, and leaves room for supporting other mutually exclusive C-states, if they come in the future. Today 'intel_idle' can only be compiled-in, which means that on SPR, in order to disable C1 and enable C1E, users should boot with the following kernel argument: intel_idle.preferred_cstates=4 Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Origin: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git da0e58c038e6 Enable C1E (if requested) not only on the BSP's socket / package. Alter command line option to fit our model, and extend it to also accept string form arguments. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Release-acked-by: Henry Wang <Henry.Wang@arm.com>
* xen/arm: Allocate and free P2M pages from the P2M poolHenry Wang2022-10-111-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit sets/tearsdown of p2m pages pool for non-privileged Arm guests by calling `p2m_set_allocation` and `p2m_teardown_allocation`. - For dom0, P2M pages should come from heap directly instead of p2m pool, so that the kernel may take advantage of the extended regions. - For xl guests, the setting of the p2m pool is called in `XEN_DOMCTL_shadow_op` and the p2m pool is destroyed in `domain_relinquish_resources`. Note that domctl->u.shadow_op.mb is updated with the new size when setting the p2m pool. - For dom0less domUs, the setting of the p2m pool is called before allocating memory during domain creation. Users can specify the p2m pool size by `xen,domain-p2m-mem-mb` dts property. To actually allocate/free pages from the p2m pool, this commit adds two helper functions namely `p2m_alloc_page` and `p2m_free_page` to `struct p2m_domain`. By replacing the `alloc_domheap_page` and `free_domheap_page` with these two helper functions, p2m pages can be added/removed from the list of p2m pool rather than from the heap. Since page from `p2m_alloc_page` is cleaned, take the opportunity to remove the redundant `clean_page` in `p2m_create_table`. This is part of CVE-2022-33747 / XSA-409. Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
* libxl, docs: Add per-arch extra default paging memoryHenry Wang2022-10-111-0/+5
| | | | | | | | | | | | | | | | | | This commit adds a per-arch macro `EXTRA_DEFAULT_PAGING_MEM_MB` to the default paging memory size, in order to cover the p2m pool for extended regions of a xl-based guest on Arm. For Arm, the extra default paging memory is 128MB. For x86, the extra default paging memory is zero, since there are no extended regions on x86. Also update the xl.cfg documentation to add Arm documentation according to code changes. This is part of CVE-2022-33747 / XSA-409. Signed-off-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Julien Grall <jgrall@amazon.com>
* drivers/char: add console=ehci as an alias for console=dbgpMarek Marczykowski-Górecki2022-09-261-2/+2
| | | | | | | | Make it consistent with console=xhci. Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Acked-by: Jan Beulich <jbeulich@suse.com>
* drivers/char: allow driving the rest of XHCI by a domain while Xen uses DbCMarek Marczykowski-Górecki2022-09-261-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | That's possible, because the capability was designed specifically to allow separate driver handle it, in parallel to unmodified xhci driver (separate set of registers, pretending the port is "disconnected" for the main xhci driver etc). It works with Linux dom0, although requires an awful hack - re-enabling bus mastering behind dom0's backs. Linux driver does similar thing - see drivers/usb/early/xhci-dbc.c:xdbc_handle_events(). When controller sharing is enabled in kconfig (option marked as experimental), dom0 is allowed to use the controller even if Xen uses it for debug console. Additionally, option `dbgp=xhci,share=` is available to either prevent even dom0 from using it (`no` value), or allow any domain using it (`any` value). In any case, to avoid Linux messing with the DbC, mark this MMIO area as read-only. This might cause issues for Linux's driver (if it tries to write something on the same page - like anoter xcap), but makes Xen's use safe. In practice, as of Linux 5.18, it seems to work without issues. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
View Lorry Controller Status