RE: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

Hi Jan, > -Original Message- > From: Jan Beulich > Sent: 2022年7月1日 13:54 > To: Wei Chen > Cc: nd ; Stefano Stabellini ; Bertrand > Marquis ; Volodymyr Babchuk > ; Andrew Cooper ; > Roger Pau Monné ; Wei Liu ; Jiamei Xie > ; xen-devel@lists.xenproject.org; Julien Grall > > Subject: Re: [

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

On Fri, Jul 01, 2022 at 07:56:28AM +0200, Juergen Gross wrote: > On 30.06.22 18:54, Demi Marie Obenour wrote: > > On Thu, Jun 30, 2022 at 03:16:41PM +0200, Juergen Gross wrote: > > > On 30.06.22 13:34, Greg KH wrote: > > > > On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote: > > >

Re: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

On 30.06.2022 14:36, Jan Beulich wrote: > On 30.06.2022 13:25, Wei Chen wrote: >>> From: Jan Beulich >>> Sent: 2022年6月24日 18:09 >>> >>> On 24.06.2022 12:05, Jan Beulich wrote: On 24.06.2022 11:49, Julien Grall wrote: >> --- a/xen/arch/arm/efi/Makefile >> +++ b/xen/arch/arm/efi

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

On 30.06.22 18:54, Demi Marie Obenour wrote: On Thu, Jun 30, 2022 at 03:16:41PM +0200, Juergen Gross wrote: On 30.06.22 13:34, Greg KH wrote: On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote: commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream unmap_grant_pages() curren

Re: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

On 01.07.2022 05:11, Wei Chen wrote: > Hi Jan, > >> -Original Message- >> From: Jan Beulich >> Sent: 2022年6月30日 20:36 >> To: Wei Chen >> Cc: nd ; Stefano Stabellini ; Bertrand >> Marquis ; Volodymyr Babchuk >> ; Andrew Cooper ; >> Roger Pau Monné ; Wei Liu ; Jiamei Xie >> ; xen-devel@lis

[linux-linus test] 171429: regressions - FAIL

flight 171429 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/171429/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 171277 test-amd64-amd64-xl

RE: [PATCH v3] public/io: xs_wire: Document that new errors should be added at the end

Hi Juergen, > -Original Message- > On 01.07.22 04:19, Henry Wang wrote: > > Hi Julien, > > > >> -Original Message- > >> Subject: [PATCH v3] public/io: xs_wire: Document that new errors should > be > >> added at the end > >> > >> From: Julien Grall > >> > >> Some tools (e.g. xensto

Re: [PATCH v3] public/io: xs_wire: Document that new errors should be added at the end

On 30.06.22 20:36, Julien Grall wrote: From: Julien Grall Some tools (e.g. xenstored) always expect EINVAL to be first in xsd_errors. To be conservative, mandate that new errors should be added at the end of the array. Signed-off-by: Julien Grall Reviewed-by: Juergen Gross Juergen Ope

Re: [PATCH v3] public/io: xs_wire: Document that new errors should be added at the end

On 01.07.22 04:19, Henry Wang wrote: Hi Julien, -Original Message- Subject: [PATCH v3] public/io: xs_wire: Document that new errors should be added at the end From: Julien Grall Some tools (e.g. xenstored) always expect EINVAL to be first in xsd_errors. To be conservative, mandate t

RE: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

Hi Jan, > -Original Message- > From: Jan Beulich > Sent: 2022年6月30日 20:36 > To: Wei Chen > Cc: nd ; Stefano Stabellini ; Bertrand > Marquis ; Volodymyr Babchuk > ; Andrew Cooper ; > Roger Pau Monné ; Wei Liu ; Jiamei Xie > ; xen-devel@lists.xenproject.org; Julien Grall > > Subject: Re:

[linux-5.4 test] 171427: regressions - FAIL

flight 171427 linux-5.4 real [real] flight 171434 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/171427/ http://logs.test-lab.xenproject.org/osstest/logs/171434/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: t

RE: [PATCH v3] public/io: xs_wire: Document that new errors should be added at the end

Hi Julien, > -Original Message- > Subject: [PATCH v3] public/io: xs_wire: Document that new errors should be > added at the end > > From: Julien Grall > > Some tools (e.g. xenstored) always expect EINVAL to be first in xsd_errors. > > To be conservative, mandate that new errors should

[xen-unstable-smoke test] 171430: tolerable all pass - PUSHED

flight 171430 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/171430/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [PATCH v9 0/3] Adds starting the idle domain privileged

On 6/30/22 18:35, Stefano Stabellini wrote: > On Wed, 29 Jun 2022, Daniel P. Smith wrote: >> This series makes it so that the idle domain is started privileged under the >> default policy, which the SILO policy inherits, and under the flask policy. >> It >> then introduces a new one-way XSM hook

[PATCH 4.14] xen/gntdev: Avoid blocking in unmap_grant_pages()

unmap_grant_pages() currently waits for the pages to no longer be used. In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a deadlock against i915: i915 was waiting for gntdev's MMU notifier to finish, while gntdev was waiting for i915 to free its pages. I also believe this is re

[PATCH 4.9] xen/gntdev: Avoid blocking in unmap_grant_pages()

unmap_grant_pages() currently waits for the pages to no longer be used. In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a deadlock against i915: i915 was waiting for gntdev's MMU notifier to finish, while gntdev was waiting for i915 to free its pages. I also believe this is re

[PATCH 4.19] xen/gntdev: Avoid blocking in unmap_grant_pages()

unmap_grant_pages() currently waits for the pages to no longer be used. In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a deadlock against i915: i915 was waiting for gntdev's MMU notifier to finish, while gntdev was waiting for i915 to free its pages. I also believe this is re

[PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

unmap_grant_pages() currently waits for the pages to no longer be used. In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a deadlock against i915: i915 was waiting for gntdev's MMU notifier to finish, while gntdev was waiting for i915 to free its pages. I also believe this is re

[PATCH 5.4] xen/gntdev: Avoid blocking in unmap_grant_pages()

unmap_grant_pages() currently waits for the pages to no longer be used. In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a deadlock against i915: i915 was waiting for gntdev's MMU notifier to finish, while gntdev was waiting for i915 to free its pages. I also believe this is re

Hopefully correct backports for gntdev deadlock

This backports "xen/gntdev: Avoid blocking in unmap_grant_pages()" to the various stable trees, hopefully correctly.

[qemu-mainline test] 171424: tolerable FAIL - PUSHED

flight 171424 qemu-mainline real [real] flight 171432 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/171424/ http://logs.test-lab.xenproject.org/osstest/logs/171432/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-ar

Re: [PATCH 5/7] xen/arm32: mm: Consolidate the domheap mappings initialization

Hi Michal, On 27/06/2022 08:24, Michal Orzel wrote: On 24.06.2022 11:11, Julien Grall wrote: From: Julien Grall At the moment, the domheap mappings initialization is done separately for the boot CPU and secondary CPUs. The main difference is for the former the pages are part of Xen binary whi

Re: [PATCH v9 0/3] Adds starting the idle domain privileged

On Wed, 29 Jun 2022, Daniel P. Smith wrote: > This series makes it so that the idle domain is started privileged under the > default policy, which the SILO policy inherits, and under the flask policy. It > then introduces a new one-way XSM hook, xsm_transition_running, that is hooked > by an XSM po

Re: [PATCH V6 1/2] xen/gnttab: Store frame GFN in struct page_info on Arm

Hi Jan, On 24/06/2022 07:45, Jan Beulich wrote: On 23.06.2022 19:50, Julien Grall wrote: On 11/05/2022 19:47, Oleksandr Tyshchenko wrote: @@ -1505,7 +1507,23 @@ int xenmem_add_to_physmap_one( } /* Map at new location. */ -rc = guest_physmap_add_entry(d, gfn, mfn, 0, t);

Re: [PATCH] xen: arm: Don't use stop_cpu() in halt_this_cpu()

On Thu, 30 Jun 2022, Bertrand Marquis wrote: > > On 29 Jun 2022, at 18:19, Stefano Stabellini wrote: > > On Wed, 29 Jun 2022, Julien Grall wrote: > >> On 28/06/2022 23:56, Stefano Stabellini wrote: > The advantage of the panic() is it will remind us that some needs to be > fixed. >

Re: [XEN PATCH v3 25/25] tools: Remove -Werror everywhere else

On Thu, 30 Jun 2022, Bertrand Marquis wrote: > > On 29 Jun 2022, at 18:22, Stefano Stabellini wrote: > > > > On Wed, 29 Jun 2022, Luca Fancellu wrote: > >> + CC: Stefano Stabellini > >> > >>> On 24 Jun 2022, at 17:04, Anthony PERARD > >>> wrote: > >>> > >>> Patch "tools: Add -Werror by defaul

[xen-unstable-smoke test] 171428: tolerable all pass - PUSHED

flight 171428 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/171428/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

Re: [PATCH v2] docs/misra: Add instructions for cppcheck

Hi Luca, On 29/06/2022 13:55, Luca Fancellu wrote: Add instructions on how to build cppcheck, the version currently used and an example to use the cppcheck integration to run the analysis on the Xen codebase Signed-off-by: Luca Fancellu --- Changes in v2: - typo fixes, removed build command li

Re: [PATCH] xen: arm: Don't use stop_cpu() in halt_this_cpu()

Hi Dmitry, On 23/06/2022 08:44, dmitry.semen...@gmail.com wrote: From: Dmytro Semenets When shutting down (or rebooting) the platform, Xen will call stop_cpu() on all the CPUs but one. The last CPU will then request the system to shutdown/restart. On platform using PSCI, stop_cpu() will call

Re: [PATCH v2 2/2] public/io: xs_wire: Allow Xenstore to report EPERM

Hi Juergen, On 27/06/2022 15:52, Juergen Gross wrote: On 27.06.22 14:36, Julien Grall wrote: From: Julien Grall C Xenstored is using EPERM when the client is not allowed to change the owner (see GET_PERMS). However, the xenstore protocol doesn't describe EPERM so EINVAL will be sent to the cl

[PATCH v3] public/io: xs_wire: Document that new errors should be added at the end

From: Julien Grall Some tools (e.g. xenstored) always expect EINVAL to be first in xsd_errors. To be conservative, mandate that new errors should be added at the end of the array. Signed-off-by: Julien Grall Changes in v3: - Mandate that new errors should be added at the end. Chang

Re: [PATCH V10 1/3] libxl: Add support for Virtio disk configuration

On 30.06.22 15:24, Juergen Gross wrote: Hello Juergen On 30.06.22 14:18, Oleksandr wrote: Dear all. On 25.06.22 17:32, Oleksandr wrote: On 24.06.22 15:59, George Dunlap wrote: Hello George On 17 Jun 2022, at 17:14, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This p

[linux-linus test] 171420: regressions - FAIL

flight 171420 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/171420/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 171277 test-amd64-amd64-xl

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

On Thu, Jun 30, 2022 at 03:16:41PM +0200, Juergen Gross wrote: > On 30.06.22 13:34, Greg KH wrote: > > On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote: > > > commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream > > > > > > unmap_grant_pages() currently waits for the pages to

Re: [PATCH v2 2/2] x86/spec-ctrl: Knobs for STIBP and PSFD, and follow hardware STIBP hint

On Wed, Jun 29, 2022 at 07:45:08PM +0100, Andrew Cooper wrote: > STIBP and PSFD are slightly weird bits, because they're both implied by other > bits in MSR_SPEC_CTRL. Add fine grain controls for them, and take the > implications into account when setting IBRS/SSBD. > > Rearrange the IBPB text/va

Re: [PATCH v2 1/2] x86/spec-ctrl: Only adjust MSR_SPEC_CTRL for idle with legacy IBRS

On Wed, Jun 29, 2022 at 07:45:07PM +0100, Andrew Cooper wrote: > Back at the time of the original Spectre-v2 fixes, it was recommended to clear > MSR_SPEC_CTRL when going idle. This is because of the side effects on the > sibling thread caused by the microcode IBRS and STIBP implementations which

[PATCH v2] x86/ept: fix shattering of special pages

The current logic in epte_get_entry_emt() will split any page marked as special with order greater than zero, without checking whether the super page is all special. Fix this by only splitting the page only if it's not all marked as special, in order to prevent unneeded super page shuttering. The

[linux-5.4 test] 171416: regressions - FAIL

flight 171416 linux-5.4 real [real] flight 171426 linux-5.4 real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/171416/ http://logs.test-lab.xenproject.org/osstest/logs/171426/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: t

Re: [PATCH v9 3/3] xsm: refactor flask sid alloc and domain check

On 6/30/22 04:40, Henry Wang wrote: > Hi Daniel, > >> -Original Message- >> Subject: [PATCH v9 3/3] xsm: refactor flask sid alloc and domain check >> >> The function flask_domain_alloc_security() is where a default sid should be >> assigned to a domain under construction. For reasons unkno

Re: [PATCH v9 1/3] xsm: create idle domain privileged and demote after setup

On 6/30/22 05:24, Roger Pau Monné wrote: > On Wed, Jun 29, 2022 at 10:21:08PM -0400, Daniel P. Smith wrote: >> There are new capabilities, dom0less and hyperlaunch, that introduce internal >> hypervisor logic, which needs to make resource allocation calls that are >> protected by XSM access check

Re: [PATCH v9 3/3] xsm: refactor flask sid alloc and domain check

On 6/30/22 02:14, Jan Beulich wrote: > Just a two nits - while the change looks plausible, I'm afraid I'm > not qualified to properly review it. > > On 30.06.2022 04:21, Daniel P. Smith wrote: >> The function flask_domain_alloc_security() is where a default sid should be >> assigned to a domain un

[ImageBuilder][PATCH v2 3/4] uboot-script-gen: Enable appending extra commands to boot script

From: Andrei Cherechesu Added the "-a" parameter which stands for APPEND_EXTRA_CMDS option, which enables the user to specify the path to a text file that contains, on each line, u-boot commands that will be added to the generated script as "fixups", before the boot command. The file specified v

[ImageBuilder][PATCH v2 2/4] uboot-script-gen: Dynamically compute addr and size when loading binaries

From: Andrei Cherechesu Normally, the script would precompute the sizes of the loaded binaries and addresses where they are loaded before generating the script, and the sizes and addresses that needed to be provided to Xen via /chosen would be hardcoded in the boot script. Added option via "-s"

[ImageBuilder][PATCH v2 0/4] Add extra ImageBuilder features

From: Andrei Cherechesu Hello, Sorry for the late re-submission of patches, but I had some company internal work to take care of. I managed to include the changes mentioned by Stefano S. and Ayan K. H. in the discussions for the first version of patches. Changes in v2: - Dropped the patch whic

[ImageBuilder][PATCH v2 1/4] scripts: Add support for prepending path to file names

From: Andrei Cherechesu Added support for prepending path to file names in the final generated u-boot script, for the use-case where we have the files in a separate folder that can be accessed with a given $LOAD_CMD. For example, we can have "fatload mmc 0:2" as LOAD_CMD but the files would need

[ImageBuilder][PATCH v2 4/4] uboot-script-gen: Enable not adding boot command to script

From: Andrei Cherechesu If the "BOOT_CMD" variable is set to "none" inside the config file, the boot command (i.e. "booti") will not by added to the generated script, to allow the user to customize the u-boot env or the device-tree after executing the script commands and before actually booting.

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

On Thu, Jun 30, 2022 at 03:16:41PM +0200, Juergen Gross wrote: > On 30.06.22 13:34, Greg KH wrote: > > On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote: > > > commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream > > > > > > unmap_grant_pages() currently waits for the pages to

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

On 30.06.22 13:34, Greg KH wrote: On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote: commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream unmap_grant_pages() currently waits for the pages to no longer be used. In https://github.com/QubesOS/qubes-issues/issues/7481, this lea

Re: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

On 30.06.2022 13:25, Wei Chen wrote: >> From: Jan Beulich >> Sent: 2022年6月24日 18:09 >> >> On 24.06.2022 12:05, Jan Beulich wrote: >>> On 24.06.2022 11:49, Julien Grall wrote: > --- a/xen/arch/arm/efi/Makefile > +++ b/xen/arch/arm/efi/Makefile > @@ -1,4 +1,12 @@ >

Re: [PATCH V10 1/3] libxl: Add support for Virtio disk configuration

On 30.06.22 14:18, Oleksandr wrote: Dear all. On 25.06.22 17:32, Oleksandr wrote: On 24.06.22 15:59, George Dunlap wrote: Hello George On 17 Jun 2022, at 17:14, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds basic support for configuring and assisting virtio-

Re: R: R: R: Crash when using xencov

On 30.06.2022 11:07, Carmine Cesarano wrote: > Sorry for the images on the ML. Please note how Julien had also asked you to not top-post. > If I wanted to change my setup instead, is there a tested and working version > of gcc for xencov features on xen stable-4.16? > (I read GCC 3.4 or later in

[qemu-mainline test] 171412: regressions - FAIL

flight 171412 qemu-mainline real [real] flight 171423 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/171412/ http://logs.test-lab.xenproject.org/osstest/logs/171423/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH V10 1/3] libxl: Add support for Virtio disk configuration

Dear all. On 25.06.22 17:32, Oleksandr wrote: On 24.06.22 15:59, George Dunlap wrote: Hello George On 17 Jun 2022, at 17:14, Oleksandr Tyshchenko wrote: From: Oleksandr Tyshchenko This patch adds basic support for configuring and assisting virtio-mmio based virtio-disk backend (emu

[xen-unstable test] 171415: tolerable FAIL

flight 171415 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/171415/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 171402 test-armhf-armhf-libvirt 16 save

Re: [PATCH 2/2] uboot-script-gen: do not enable direct mapping by default

Hi Ayan, On 6/30/22 14:28, Ayan Kumar Halder wrote: On 29/06/2022 21:28, Stefano Stabellini wrote: On Wed, 29 Jun 2022, Ayan Kumar Halder wrote: Hi Stefano/Xenia, On 29/06/2022 18:01, xenia wrote: Hi Stefano, On 6/29/22 03:28, Stefano Stabellini wrote: On Sun, 26 Jun 2022, Xenia Ragiadako

RE: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

> -Original Message- > From: Xen-devel On Behalf Of Wei > Chen > Sent: 2022年6月30日 19:25 > To: Jan Beulich ; Julien Grall > Cc: nd ; Stefano Stabellini ; Bertrand > Marquis ; Volodymyr Babchuk > ; Andrew Cooper ; > Roger Pau Monné ; Wei Liu ; Jiamei Xie > ; xen-devel@lists.xenproject.org

Re: [PATCH 5.10] xen/gntdev: Avoid blocking in unmap_grant_pages()

On Mon, Jun 27, 2022 at 02:10:02PM -0400, Demi Marie Obenour wrote: > commit dbe97cff7dd9f0f75c524afdd55ad46be3d15295 upstream > > unmap_grant_pages() currently waits for the pages to no longer be used. > In https://github.com/QubesOS/qubes-issues/issues/7481, this lead to a > deadlock against i91

Re: [PATCH 2/2] uboot-script-gen: do not enable direct mapping by default

On 29/06/2022 21:28, Stefano Stabellini wrote: On Wed, 29 Jun 2022, Ayan Kumar Halder wrote: Hi Stefano/Xenia, On 29/06/2022 18:01, xenia wrote: Hi Stefano, On 6/29/22 03:28, Stefano Stabellini wrote: On Sun, 26 Jun 2022, Xenia Ragiadakou wrote: To be inline with XEN, do not enable direct

RE: [PATCH v6 1/8] xen: reuse x86 EFI stub functions for Arm

Hi Julien and Jan, > -Original Message- > From: Jan Beulich > Sent: 2022年6月24日 18:09 > To: Julien Grall > Cc: nd ; Stefano Stabellini ; Bertrand > Marquis ; Volodymyr Babchuk > ; Andrew Cooper ; > Roger Pau Monné ; Wei Liu ; Jiamei Xie > ; xen-devel@lists.xenproject.org; Wei Chen > > Su

[ovmf test] 171422: all pass - PUSHED

flight 171422 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/171422/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 8d0564deafc90df8531b086a483707cfcfac2b54 baseline version: ovmf 21e6ef752239c3c840bc3

Re: [PATCH v9 1/3] xsm: create idle domain privileged and demote after setup

On Wed, Jun 29, 2022 at 10:21:08PM -0400, Daniel P. Smith wrote: > There are new capabilities, dom0less and hyperlaunch, that introduce internal > hypervisor logic, which needs to make resource allocation calls that are > protected by XSM access checks. The need for these resource allocations are >

R: R: R: Crash when using xencov

Hello, Sorry for the images on the ML. If I wanted to change my setup instead, is there a tested and working version of gcc for xencov features on xen stable-4.16? (I read GCC 3.4 or later in the documentation). Cheers, Carmine Cesarano Da: Julien Grall Inviato: mercoledì

[libvirt test] 171419: regressions - FAIL

flight 171419 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/171419/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt

[PATCH v2 6/6] x86/irq: do not set nr_irqs based on nr_irqs_gsi in APIC mode

When using an APIC do not set nr_irqs based on a factor of nr_irqs_gsi (currently x8), and instead do so exclusively based on the amount of available vectors on the system. There's no point in setting nr_irqs to a value higher than the available set of vectors, as vector allocation will fail anywa

[PATCH v2 5/6] x86/irq: print nr_irqs as limit on the number of MSI(-X) interrupts

Using nr_irqs minus nr_irqs_gsi is misleading, as GSI interrupts are not allocated unless requested by the hardware domain, so a hardware domain could not use any GSI (or just one for the ACPI SCI), and hence (almost) all nr_irqs will be available for MSI(-X) usage. No functional difference, just

[PATCH v2 4/6] x86/irq: fix setting irq limits

Current code to calculate nr_irqs assumes the APIC destination mode to be physical, so all vectors on each possible CPU is available for use by a different interrupt source. This is not true when using Logical (Cluster) destination mode, where CPUs in the same cluster share the vector space. Fix b

[PATCH v2 3/6] x86/setup: init nr_irqs after having detected x2APIC support

Logic in ioapic_init() that sets the number of available vectors for external interrupts requires knowing the x2APIC Destination Mode. As such move the call after x2APIC BSP setup. Do it as part of init_irq_data(), which is called just after x2APIC BSP init and also makes use of nr_irqs itself.

[PATCH v2 0/6] x86/irq: switch x2APIC default destination mode

Hello, The following series aims to change the default x2APIC Destination mode from Logical to Physical. This is done in order to cope with boxes that don't have a huge amount of CPUs, but do have a non trivial amount of PCI devices using MSI(-X). The default x2APIC destination mode can now be s

[PATCH v2 2/6] x86/x2apic: use physical destination mode by default

Using cluster mode by default greatly limits the amount of vectors available, as then vector space is shared amongst all the CPUs in the logical cluster. This can lead to vector shortage issues on boxes with not a huge amount of CPUs but with a non-trivial amount of devices. There are reports of

[PATCH v2 1/6] x86/Kconfig: add option for default x2APIC destination mode

Allow setting the default x2APIC destination mode from Kconfig to Physical. Note the default destination mode is still Logical (Cluster) mode. Signed-off-by: Roger Pau Monné --- Changes since v1: - Use a boolean rather than a choice. - Expand to X2APIC_PHYSICAL. --- TBH I wasn't sure whether t

Re: [PATCH v2 1/2] console/serial: set the default transmit buffer size in Kconfig

On 30.06.2022 10:23, Roger Pau Monne wrote: > Take the opportunity to convert the variable to read-only after init. > > No functional change intended. > > Signed-off-by: Roger Pau Monné Reviewed-by: Jan Beulich

RE: [PATCH v9 3/3] xsm: refactor flask sid alloc and domain check

Hi Daniel, > -Original Message- > Subject: [PATCH v9 3/3] xsm: refactor flask sid alloc and domain check > > The function flask_domain_alloc_security() is where a default sid should be > assigned to a domain under construction. For reasons unknown, the initial > domain would be assigned u

[ovmf test] 171418: all pass - PUSHED

flight 171418 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/171418/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 21e6ef752239c3c840bc31745e14b391bf9c4691 baseline version: ovmf c13377153f74d66adc837

[PATCH v2 1/2] console/serial: set the default transmit buffer size in Kconfig

Take the opportunity to convert the variable to read-only after init. No functional change intended. Signed-off-by: Roger Pau Monné --- Changes since v1: - Fix help message about rounded boundary, do not round up the default value (will be done at runtime). - Use kiB instead of KB. --- xen

[PATCH v2 0/2] console/serial: adjust default TX buffer size

Hello, First patch moves the setting of the default TX buffer size to Kconfig, and shouldn't be controversial, second patch increases the buffer to 32K. Jan doesn't feel comfortable Acking patch 2, so someone will have to review and consider it, see: https://lore.kernel.org/xen-devel/59fe1b28-b1

[PATCH v2 2/2] console/serial: bump buffer from 16K to 32K

Testing on a Kaby Lake box with 8 CPUs leads to the serial buffer being filled halfway during dom0 boot, and thus a non-trivial chunk of Linux boot messages are dropped. Increasing the buffer to 32K does fix the issue and Linux boot messages are no longer dropped. There's no justification either

Re: [PATCH] xen: Fix spelling mistake

On 30.06.22 09:50, Zhang Jiaming wrote: Change 'maped' to 'mapped'. Change 'unmaped' to 'unmapped'. Signed-off-by: Zhang Jiaming Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature

Re: [PATCH 2/2] console/serial: bump buffer from 16K to 32K

On Wed, Jun 29, 2022 at 06:30:18PM +0200, Jan Beulich wrote: > On 29.06.2022 18:19, Roger Pau Monné wrote: > > On Wed, Jun 29, 2022 at 06:03:34PM +0200, Jan Beulich wrote: > >> On 29.06.2022 17:23, Roger Pau Monné wrote: > >>> On Thu, Jun 23, 2022 at 03:32:30PM +0200, Jan Beulich wrote: > On 2

[PATCH] xen: Fix spelling mistake

Change 'maped' to 'mapped'. Change 'unmaped' to 'unmapped'. Signed-off-by: Zhang Jiaming --- drivers/xen/xen-front-pgdir-shbuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/xen/xen-front-pgdir-shbuf.c b/drivers/xen/xen-front-pgdir-shbuf.c index bef8d72a6ca6..

Re: [XEN PATCH v3 25/25] tools: Remove -Werror everywhere else

Hi Stefano, > On 29 Jun 2022, at 18:22, Stefano Stabellini wrote: > > On Wed, 29 Jun 2022, Luca Fancellu wrote: >> + CC: Stefano Stabellini >> >>> On 24 Jun 2022, at 17:04, Anthony PERARD wrote: >>> >>> Patch "tools: Add -Werror by default to all tools/" have added >>> "-Werror" to CFLAGS in

Re: [PATCH] xen: arm: Don't use stop_cpu() in halt_this_cpu()

Hi, > On 29 Jun 2022, at 18:19, Stefano Stabellini wrote: > > On Wed, 29 Jun 2022, Julien Grall wrote: >> On 28/06/2022 23:56, Stefano Stabellini wrote: The advantage of the panic() is it will remind us that some needs to be fixed. With a warning (or WARN()) people will tend to ig

[PATCH v3 0/3] x86: fix brk area initialization

The brk area needs to be zeroed initially, like the .bss section. At the same time its memory should be covered by the ELF program headers. Juergen Gross (3): x86/xen: use clear_bss() for Xen PV guests x86: clear .brk area at early boot x86: fix .brk attribute in linker script arch/x86/inc

[PATCH v3 2/3] x86: clear .brk area at early boot

The .brk section has the same properties as .bss: it is an alloc-only section and should be cleared before being used. Not doing so is especially a problem for Xen PV guests, as the hypervisor will validate page tables (check for writable page tables and hypervisor private bits) before accepting t

[PATCH v3 3/3] x86: fix .brk attribute in linker script

Commit e32683c6f7d2 ("x86/mm: Fix RESERVE_BRK() for older binutils") added the "NOLOAD" attribute to the .brk section as a "failsafe" measure. Unfortunately this leads to the linker no longer covering the .brk section in a program header, resulting in the kernel loader not knowing that the memory

[PATCH v3 1/3] x86/xen: use clear_bss() for Xen PV guests

Instead of clearing the bss area in assembly code, use the clear_bss() function. This requires to pass the start_info address as parameter to xen_start_kernel() in order to avoid the xen_start_info being zeroed again. Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Reviewed-by: Boris Ostr