[qemu-mainline test] 181461: regressions - FAIL

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

[linux-5.4 test] 181448: regressions - trouble: blocked/broken/fail/pass

flight 181448 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/181448/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl broken build-amd64-pvops 6

RE: [PATCH v3] iommu/vtd: fix address translation for leaf entries

> From: Roger Pau Monne > Sent: Thursday, May 25, 2023 4:09 PM > > Fix two issues related to leaf address lookups in VT-d: > > * When translating an address that falls inside of a superpage in the > IOMMU page tables the fetching of the PTE value wasn't masking of the > contiguous related

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

flight 181457 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/181457/ 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

[xen-unstable test] 181440: trouble: broken/fail/pass

flight 181440 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/181440/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-vhd broken Tests which are

[qemu-mainline test] 181446: regressions - FAIL

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

Re: [XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

On Thu, 15 Jun 2023, Roberto Bagnara wrote: > This document specifies the C language dialect used by Xen and > the assumptions Xen makes on the translation toolchain. > > Signed-off-by: Roberto Bagnara Thanks Roberto for the amazing work of research and archaeology. I have a few comments

Re: Asking for help to debug xen efi on Kunpeng machine

Hello Julien, Thank you for your answer! Adding console=hvc0 indeed provides kernel output serial console. Looking at the log message, I found dom0 kernel failed to initialize a lot of device drivers (network cards, raid cards, etc). Is it related to iommu? I remember iommu is not enabled

[PATCH v2] xen/misra: add rules 1.4 and 2.1

From: Stefano Stabellini Also add a comment at the top of the file to say rules.rst could be changed. Signed-off-by: Stefano Stabellini --- Changes in v2: - add link for 1.4 - expand 1.4 comment to say it could be revisited - add comment at the top --- docs/misra/rules.rst | 15

Re: [PATCH] xen/misra: add rules 1.4 and 2.1

On Thu, 15 Jun 2023, Jan Beulich wrote: > On 15.06.2023 01:03, Stefano Stabellini wrote: > > --- a/docs/misra/rules.rst > > +++ b/docs/misra/rules.rst > > @@ -90,6 +90,17 @@ existing codebase are work-in-progress. > > behaviour > > - > > > > + * - Rule 1.4 > > + - Required >

Re: [PATCH] xen/misra: add rules 1.4 and 2.1

On Thu, 15 Jun 2023, Michal Orzel wrote: > Hi Stefano, > > On 15/06/2023 01:03, Stefano Stabellini wrote: > > Caution: This message originated from an External Source. Use proper > > caution when opening attachments, clicking links, or responding. > > > > > > From: Stefano Stabellini > > > >

[PATCH v5] docs/misra: new rules addition

From: Stefano Stabellini For Dir 1.1, a document describing all implementation-defined behaviour (i.e. gcc-specific behavior) will be added to docs/misra, also including implementation-specific (gcc-specific) appropriate types for bit-field relevant to Rule 6.1. Rule 21.21 is lacking an example

Re: [PATCH v4] docs/misra: new rules addition

On Thu, 15 Jun 2023, Michal Orzel wrote: > Hi Stefano, > > On 15/06/2023 00:55, Stefano Stabellini wrote: > > > > > > From: Stefano Stabellini > > > > For Dir 1.1, a document describing all implementation-defined behaviour > > (i.e. gcc-specific behavior) will be added to docs/misra, also

Re: [PATCH v4 0/7] SMMU handling for PCIe Passthrough on ARM

On 6/7/23 03:19, Julien Grall wrote: > Hi Stewart, > > On 07/06/2023 04:02, Stewart Hildebrand wrote: >> This series introduces SMMU handling for PCIe passthrough on ARM. These >> patches >> are independent from (and don't depend on) the vPCI reference >> counting/locking >> work in progress,

Re: [PATCH v3 13/16] tools/xenstore: replace xs_lib.c with a header

Hi Juergen, On 30/05/2023 09:54, Juergen Gross wrote: Instead of including the same small C source in multiple binaries from 2 source directories, use a header file with inline functions as a replacement. As some of the functions are exported by libxenstore, rename the inline functions from

Re: [PATCH 1/4] xen/arm: debug-pl011: Use correct accessors

On Thu, 15 Jun 2023, Michal Orzel wrote: > Hi Stefano, > > On 15/06/2023 03:36, Stefano Stabellini wrote: > > > > > > On Wed, 7 Jun 2023, Michal Orzel wrote: > >> Although most PL011 UARTs can cope with 32-bit accesses, some of the old > >> legacy ones might not. PL011 registers are 8/16-bit

Re: [PATCH v3 12/16] tools/xenstore: remove no longer needed functions from xs_lib.c

Hi Juergen, On 30/05/2023 09:54, Juergen Gross wrote: xs_daemon_tdb() in xs_lib.c is no longer used at all, so it can be removed. xs_domain_dev() and xs_write_all() are not used by xenstored, so they can be moved to tools/libs/store/xs.c. xs_daemon_rootdir() is used by xenstored only and it

Re: [PATCH] xen: Append a newline character to panic() where missing

Hi, On 14/06/2023 10:09, Julien Grall wrote: The patch looks fine. I will commit it a bit later just to give a chance to Bertrand/Stefano to object. And committed. Cheers, -- Julien Grall

Re: Asking for help to debug xen efi on Kunpeng machine

Hi, On 13/06/2023 02:07, Jiatong Shen wrote: Hello Stefano and Julien, Could you provide more insights for debugging? I tried to connect to serial console through ipmitool sol activate and enabled ACPI, I do see some logs but the machine is still stuck. BMC video screen is still not

Re: [PATCH] xen/arm: Remove stray semicolon at VREG_REG_HELPERS/TLB_HELPER* callers

Hi, On 15/06/2023 00:46, Stefano Stabellini wrote: On Wed, 14 Jun 2023, Michal Orzel wrote: This is inconsistent with the rest of the code where macros are used to define functions, as it results in an empty declaration (i.e. semicolon with nothing before it) after function definition. This is

Re: [XEN v8 1/5] xen/arm: p2m: Use the pa_range_info table to support ARM_32 and ARM_64

Hi Michal, I notice you posted some comments but didn't add a Acked-by/Reviewed-by. Can you indicate if you are happy with the patch so long your comments are addressed? If so, are you OK if I deal with them on commit? Cheers, -- Julien Grall

Re: [XEN v8 5/5] xen/arm: p2m: Enable support for 32bit IPA for ARM_32

Hi Ayan, On 02/06/2023 13:07, Ayan Kumar Halder wrote: Refer ARM DDI 0406C.d ID040418, B3-1345, "A stage 2 translation with an input address range of 31-34 bits can start the translation either: - With a first-level lookup, accessing a first-level translation table with 2-16 entries. -

Re: [XEN v8 2/5] xen/arm: Introduce choice to enable 64/32 bit physical addressing

Hi Ayan, On 02/06/2023 13:07, Ayan Kumar Halder wrote: Some Arm based hardware platforms which does not support LPAE (eg Cortex-R52), uses 32 bit physical addresses. Also, users may choose to use 32 bits to represent physical addresses for optimization. To support the above use cases, we have

Re: [XEN PATCH] xen/arch/arm/traps: remove inlining of handle_ro_raz()

Hi, On 15/06/2023 15:49, Michal Orzel wrote: Hi Federico, NIT: for Arm, we use "xen/arm: " as a component name in a commit title or if you want to also specify the sub component, then "xen/arm: : " e.g. "xen/arm: traps: " On 15/06/2023 15:50, Federico Serafini wrote: To comply with MISRA

[linux-linus test] 181435: regressions - FAIL

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

[libvirt test] 181437: tolerable FAIL - PUSHED

flight 181437 libvirt real [real] flight 181450 libvirt real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/181437/ http://logs.test-lab.xenproject.org/osstest/logs/181450/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [PATCH] x86/xen: set default memory type for pv guests to WB

On 6/15/23 8:39 AM, Juergen Gross wrote: When running as an unprivileged PV-guest under Xen (not dom0), the default MTRR memory type should be write-back. Signed-off-by: Juergen Gross Reviewed-by: Boris Ostrovsky

Re: [PATCH v3 4/4] x86/cpu-policy: Derive RSBA/RRSBA for guest policies

On 15/06/2023 1:13 pm, Jan Beulich wrote: > On 15.06.2023 12:41, Andrew Cooper wrote: >> On 15/06/2023 9:30 am, Jan Beulich wrote: >>> On 14.06.2023 20:12, Andrew Cooper wrote: On 13/06/2023 10:59 am, Jan Beulich wrote: > On 12.06.2023 18:13, Andrew Cooper wrote: >> The RSBA bit, "RSB

[linux-5.4 test] 181434: regressions - FAIL

flight 181434 linux-5.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/181434/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 181363 build-amd64-pvops

Re: [PATCH v4 04/15] xen/sysctl: Nest cpufreq scaling options

On Thu, Jun 15, 2023 at 10:29 AM Jan Beulich wrote: > > On 15.06.2023 16:07, Jason Andryuk wrote: > > On Thu, Jun 15, 2023 at 9:29 AM Jan Beulich wrote: > >> > >> On 14.06.2023 20:02, Jason Andryuk wrote: > >>> --- a/tools/include/xenctrl.h > >>> +++ b/tools/include/xenctrl.h > >>> @@ -1909,16

Refactoring of a possibly unsafe pattern for variable initialization via function calls

Hi all, while investigating possible patches regarding Mandatory Rule 9.1, I found the following pattern, that is likely to results in a lot possible positives from many (all) static analysis tools for this rule. This is the current status (taken from `xen/common/device_tree.c:135') const

[qemu-mainline test] 181443: regressions - trouble: blocked/broken/fail/pass

flight 181443 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/181443/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf broken build-amd64-xsm 6

[PATCH] mm/pdx: Add comments throughout the codebase for pdx

Document the behaviour of the pdx machinery in Xen. Some logic is fairly opaque and hard to follow without it being documented anywhere. This explains the rationale behind compression and its relationship to frametable indexing and directmap management. While modifying the file: * Convert u64

Re: [PATCH v2 0/5] Prevent attempting updates known to fail

On Thu, Jun 15, 2023 at 04:48:29PM +0100, Alejandro Vallejo wrote: > v3: > * Lots of hunks moved around. Individually mentioned in each patch > * Removed a redundant check > * Ignore microcode interface if the revision is -1 > * Perform the DIS_MCU_LOAD checks during init rather than apply

[PATCH v3 4/5] x86: Read MSR_ARCH_CAPS immediately after early_microcode_init()

Move MSR_ARCH_CAPS read code from tsx_init() to immediately after the early microcode update. This helps keep the reload closer to its cause and is the earliest point we can read it, as it might be exposed only after a microcode update. Signed-off-by: Alejandro Vallejo --- v3: * Replaces

[PATCH v3 5/5] x86/microcode: Disable microcode update handler if DIS_MCU_UPDATE is set

If IA32_MSR_MCU_CONTROL exists then it's possible a CPU may be unable to perform microcode updates. This is controlled through the DIS_MCU_LOAD bit and is intended for baremetal clouds where the owner may not trust the tenant to choose the microcode version in use. If we notice that bit being set

[PATCH v3 3/5] x86/microcode: Ignore microcode loading interface for revision = -1

Some hypervisors report ~0 as the microcode revision to mean "don't issue microcode updates". Ignore the microcode loading interface in that case. Signed-off-by: Alejandro Vallejo --- v3: * Moved from v2/patch3 (Andrew) --- xen/arch/x86/cpu/microcode/core.c | 8 1 file changed, 8

[PATCH v3 2/5] x86/microcode: Create per-vendor microcode_ops builders

Replace the ucode_ops assignments in core.c for per-vendor calls. This is in preparation for another patch that adds Intel-specific conditions. While moving the code around, also remove the family check on Intel, as microcode loading is present on every Intel 64 machine. Signed-off-by: Alejandro

[PATCH v2 0/5] Prevent attempting updates known to fail

v3: * Lots of hunks moved around. Individually mentioned in each patch * Removed a redundant check * Ignore microcode interface if the revision is -1 * Perform the DIS_MCU_LOAD checks during init rather than apply time Under certain conditions a CPU may not be able to perform microcode

[PATCH v3 1/5] x86/microcode: Allow reading microcode revision even if it can't be updated

The code currently assumes all microcode handlers are set or none are. That won't be the case in a future patch, as apply_microcode() may not be set while the others are. Hence, this patch allows reading the microcode revision even if updating it is unavailable. Signed-off-by: Alejandro Vallejo

Re: [PATCH v4 05/15] pmstat: Re-arrage for cpufreq union

On Thu, Jun 15, 2023 at 11:22 AM Jan Beulich wrote: > > On 15.06.2023 17:05, Jason Andryuk wrote: > > On Thu, Jun 15, 2023 at 10:38 AM Jan Beulich wrote: > >> > >> On 14.06.2023 20:02, Jason Andryuk wrote: > >>> Move some code around now that common xen_sysctl_pm_op get_para fields > >>> are

[PATCH v2 0/2] Introduce a REQUIRE_NX Kconfig option

v2: * Created assembly override for cases where XD_DISABLE is set * Turned rdmsrl() into rdmsr_safe() when reading IA32_MSR_MISC_ENABLE in C This option hardens Xen by forcing it to write secure (NX-enhanced) PTEs regardless of the runtime NX feature bit in boot_cpu_data. This prevents an

[PATCH v2 2/2] x86: Add Kconfig option to require NX bit support

This option hardens Xen by forcing it to write secure (NX-enhanced) PTEs regardless of the runtime NX feature bit in boot_cpu_data. This prevents an attacker with partial write support from affecting Xen's PTE generation logic by overriding the NX feature flag. The patch asserts support for the NX

[PATCH v2 1/2] x86/boot: Clear XD_DISABLE from the early boot path

Intel CPUs have a bit in MSR_IA32_MISC_ENABLE that may prevent the NX bit from being advertised. Clear it unconditionally if we can't find the NX feature right away on boot. The conditions for the MSR being read on early boot are (in this order): * Long Mode is supported * NX isn't advertised *

Re: [PATCH v4 05/15] pmstat: Re-arrage for cpufreq union

On 15.06.2023 17:05, Jason Andryuk wrote: > On Thu, Jun 15, 2023 at 10:38 AM Jan Beulich wrote: >> >> On 14.06.2023 20:02, Jason Andryuk wrote: >>> Move some code around now that common xen_sysctl_pm_op get_para fields >>> are together. In particular, the scaling governor information like >>>

Re: [PATCH v4 05/15] pmstat: Re-arrage for cpufreq union

On Thu, Jun 15, 2023 at 10:38 AM Jan Beulich wrote: > > On 14.06.2023 20:02, Jason Andryuk wrote: > > Move some code around now that common xen_sysctl_pm_op get_para fields > > are together. In particular, the scaling governor information like > > scaling_available_governors is inside the union,

[PATCH v2 2/2] x86/vPIT: account for "counter stopped" time

For an approach like that used in "x86: detect PIT aliasing on ports other than 0x4[0-3]" [1] to work, channel 2 may not (appear to) continue counting when "gate" is low. Record the time when "gate" goes low, and adjust pit_get_{count,out}() accordingly. Additionally for most of the modes a rising

[PATCH v2 1/2] x86/vPIT: re-order functions

To avoid the need for a forward declaration of pit_load_count() in a subsequent change, move it earlier in the file (along with its helper callback). While moving the code, address a few style issues. Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné --- v2: Address a few style issues

[PATCH v2 0/2] x86/vPIT: account for "counter stopped" time

This addresses an observation made while putting together "x86: detect PIT aliasing on ports other than 0x4[0-3]". 1: re-order functions 2: account for "counter stopped" time Jan

Re: [XEN PATCH] xen/arch/arm/traps: remove inlining of handle_ro_raz()

Hi Federico, NIT: for Arm, we use "xen/arm: " as a component name in a commit title or if you want to also specify the sub component, then "xen/arm: : " e.g. "xen/arm: traps: " On 15/06/2023 15:50, Federico Serafini wrote: > > > To comply with MISRA C:2012 Rule 8.10 ("An inline function shall

Re: [PATCH v4 05/15] pmstat: Re-arrage for cpufreq union

On 14.06.2023 20:02, Jason Andryuk wrote: > Move some code around now that common xen_sysctl_pm_op get_para fields > are together. In particular, the scaling governor information like > scaling_available_governors is inside the union, so it is not always > available. > > With that, gov_num may

[XEN PATCH] docs/misra: document the C dialect and translation toolchain assumptions.

This document specifies the C language dialect used by Xen and the assumptions Xen makes on the translation toolchain. Signed-off-by: Roberto Bagnara --- docs/misra/C-language-toolchain.rst | 465 1 file changed, 465 insertions(+) create mode 100644

Re: [PATCH v4 04/15] xen/sysctl: Nest cpufreq scaling options

On 15.06.2023 16:07, Jason Andryuk wrote: > On Thu, Jun 15, 2023 at 9:29 AM Jan Beulich wrote: >> >> On 14.06.2023 20:02, Jason Andryuk wrote: >>> --- a/tools/include/xenctrl.h >>> +++ b/tools/include/xenctrl.h >>> @@ -1909,16 +1909,20 @@ struct xc_get_cpufreq_para { >>> uint32_t

Re: [PATCH v4 01/15] cpufreq: Allow restricting to internal governors only

On 15.06.2023 16:04, Jason Andryuk wrote: > On Thu, Jun 15, 2023 at 9:21 AM Jan Beulich wrote: >> Yet then I find this approach a little odd anyway. I think the >> registration attempts would better be suppressed, thus also not >> resulting in (apparently) failed init-calls. Especially for the >>

Re: [PATCH v4 04/15] xen/sysctl: Nest cpufreq scaling options

On Thu, Jun 15, 2023 at 9:29 AM Jan Beulich wrote: > > On 14.06.2023 20:02, Jason Andryuk wrote: > > --- a/tools/include/xenctrl.h > > +++ b/tools/include/xenctrl.h > > @@ -1909,16 +1909,20 @@ struct xc_get_cpufreq_para { > > uint32_t cpuinfo_cur_freq; > > uint32_t cpuinfo_max_freq; > >

Re: [PATCH v4 01/15] cpufreq: Allow restricting to internal governors only

On Thu, Jun 15, 2023 at 9:21 AM Jan Beulich wrote: > > On 14.06.2023 20:02, Jason Andryuk wrote: > > @@ -121,6 +122,12 @@ int __init cpufreq_register_governor(struct > > cpufreq_governor *governor) > > if (!governor) > > return -EINVAL; > > > > +if (cpufreq_governor_internal &&

[XEN PATCH] xen/arch/arm/traps: remove inlining of handle_ro_raz()

To comply with MISRA C:2012 Rule 8.10 ("An inline function shall be declared with the static storage class"), remove inline function specifier from handle_ro_raz() since asking the compiler to inline such function does not seem to add any kind of value. Signed-off-by: Federico Serafini ---

Re: [PATCH v4 04/15] xen/sysctl: Nest cpufreq scaling options

On 14.06.2023 20:02, Jason Andryuk wrote: > --- a/tools/include/xenctrl.h > +++ b/tools/include/xenctrl.h > @@ -1909,16 +1909,20 @@ struct xc_get_cpufreq_para { > uint32_t cpuinfo_cur_freq; > uint32_t cpuinfo_max_freq; > uint32_t cpuinfo_min_freq; > -uint32_t scaling_cur_freq; >

Re: [PATCH v4 01/15] cpufreq: Allow restricting to internal governors only

On 14.06.2023 20:02, Jason Andryuk wrote: > @@ -121,6 +122,12 @@ int __init cpufreq_register_governor(struct > cpufreq_governor *governor) > if (!governor) > return -EINVAL; > > +if (cpufreq_governor_internal && !governor->internal) > +return -EINVAL; > + > +if

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

flight 181442 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/181442/ 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

[PATCH] x86/xen: set default memory type for pv guests to WB

When running as an unprivileged PV-guest under Xen (not dom0), the default MTRR memory type should be write-back. Signed-off-by: Juergen Gross --- Based on tip x86/mtrr branch --- arch/x86/xen/enlighten_pv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/xen/enlighten_pv.c

Re: [XEN PATCH] xen/include/xen/lib.h: avoid undefined behavior.

On 15.06.2023 12:30, Nicola Vetrini wrote: > --- a/xen/include/xen/lib.h > +++ b/xen/include/xen/lib.h > @@ -40,22 +40,8 @@ > unlikely(ret_warn_on_); \ > }) > > -/* All clang versions supported by Xen have _Static_assert. */ > -#if defined(__clang__) || \ > -(__GNUC__ > 4

Re: [PATCH] xen/misra: add rules 1.4 and 2.1

Hi Stefano, On 15/06/2023 01:03, Stefano Stabellini wrote: > Caution: This message originated from an External Source. Use proper caution > when opening attachments, clicking links, or responding. > > > From: Stefano Stabellini > > Signed-off-by: Stefano Stabellini > --- >

Re: [PATCH v4] docs/misra: new rules addition

Hi Stefano, On 15/06/2023 00:55, Stefano Stabellini wrote: > > > From: Stefano Stabellini > > For Dir 1.1, a document describing all implementation-defined behaviour > (i.e. gcc-specific behavior) will be added to docs/misra, also including > implementation-specific (gcc-specific) appropriate

Re: [PATCH v7 00/12] PCI devices passthrough on Arm, part 3

On 15.06.2023 11:39, Volodymyr Babchuk wrote: > Stewart Hildebrand writes: >> On 6/13/23 06:32, Volodymyr Babchuk wrote: >>> Hello, >>> >>> This is another another version of vPCI rework (previous one can be >>> found at [1]). The biggest change is how vPCI locking is done. This >>> series uses

Re: [PATCH v3 4/4] x86/cpu-policy: Derive RSBA/RRSBA for guest policies

On 15.06.2023 12:41, Andrew Cooper wrote: > On 15/06/2023 9:30 am, Jan Beulich wrote: >> On 14.06.2023 20:12, Andrew Cooper wrote: >>> On 13/06/2023 10:59 am, Jan Beulich wrote: On 12.06.2023 18:13, Andrew Cooper wrote: > The RSBA bit, "RSB Alternative", means that the RSB may use

Re: [PATCH v3 4/4] x86/cpu-policy: Derive RSBA/RRSBA for guest policies

On 15/06/2023 9:30 am, Jan Beulich wrote: > On 14.06.2023 20:12, Andrew Cooper wrote: >> On 13/06/2023 10:59 am, Jan Beulich wrote: >>> On 12.06.2023 18:13, Andrew Cooper wrote: The RSBA bit, "RSB Alternative", means that the RSB may use alternative predictors when empty. From a

Re: [XEN PATCH] xen/include/xen/lib.h: avoid undefined behavior.

On 15/06/2023 11:30 am, Nicola Vetrini wrote: > Redefine BUILD_BUG_ON_ZERO to fully comply with C99 avoiding > undefined behavior 58 ("A structure or union is defined as > containing no named members (6.7.2.1)." > This also avoids a dependency on the compiler and its version. > > Signed-off-by:

[XEN PATCH] xen/include/xen/lib.h: avoid undefined behavior.

Redefine BUILD_BUG_ON_ZERO to fully comply with C99 avoiding undefined behavior 58 ("A structure or union is defined as containing no named members (6.7.2.1)." This also avoids a dependency on the compiler and its version. Signed-off-by: Nicola Vetrini --- xen/include/xen/lib.h | 16

Re: [XEN v8 1/5] xen/arm: p2m: Use the pa_range_info table to support ARM_32 and ARM_64

On 15/06/2023 10:40, Julien Grall wrote: Hi Ayan, Hi Julien, On 15/06/2023 10:29, Ayan Kumar Halder wrote: On 15/06/2023 09:05, Michal Orzel wrote: Hi Ayan, Hi Michal, On 02/06/2023 14:07, Ayan Kumar Halder wrote: Restructure the code so that one can use pa_range_info[] table for

[qemu-mainline test] 181436: regressions - FAIL

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

[ovmf test] 181438: tolerable FAIL - PUSHED

flight 181438 ovmf real [real] flight 181441 ovmf real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/181438/ http://logs.test-lab.xenproject.org/osstest/logs/181441/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [XEN v8 1/5] xen/arm: p2m: Use the pa_range_info table to support ARM_32 and ARM_64

Hi Ayan, On 15/06/2023 10:29, Ayan Kumar Halder wrote: On 15/06/2023 09:05, Michal Orzel wrote: Hi Ayan, Hi Michal, On 02/06/2023 14:07, Ayan Kumar Halder wrote: Restructure the code so that one can use pa_range_info[] table for both ARM_32 as well as ARM_64. I grepped for ARM_{32,64} in

Re: [PATCH v7 00/12] PCI devices passthrough on Arm, part 3

Hi Stewart, Stewart Hildebrand writes: > On 6/13/23 06:32, Volodymyr Babchuk wrote: >> Hello, >> >> This is another another version of vPCI rework (previous one can be >> found at [1]). The biggest change is how vPCI locking is done. This >> series uses per-domain vPCI rwlock. >> >> Note

Re: [XEN v8 1/5] xen/arm: p2m: Use the pa_range_info table to support ARM_32 and ARM_64

On 15/06/2023 09:05, Michal Orzel wrote: Hi Ayan, Hi Michal, On 02/06/2023 14:07, Ayan Kumar Halder wrote: Restructure the code so that one can use pa_range_info[] table for both ARM_32 as well as ARM_64. I grepped for ARM_{32,64} in our code base and could not find any use in source

Re: [PATCH] xen/misra: add rules 1.4 and 2.1

On 15.06.2023 01:03, Stefano Stabellini wrote: > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -90,6 +90,17 @@ existing codebase are work-in-progress. > behaviour > - > > + * - Rule 1.4 > + - Required > + - Emergent language features shall not be used > +

Re: [PATCH v3 4/4] x86/cpu-policy: Derive RSBA/RRSBA for guest policies

On 14.06.2023 20:12, Andrew Cooper wrote: > On 13/06/2023 10:59 am, Jan Beulich wrote: >> On 12.06.2023 18:13, Andrew Cooper wrote: >>> The RSBA bit, "RSB Alternative", means that the RSB may use alternative >>> predictors when empty. From a practical point of view, this mean "Retpoline >>> not

Re: [PATCH v3 3/4] x86/spec-ctrl: Fix up the RSBA/RRSBA bits as appropriate

On 14.06.2023 19:25, Andrew Cooper wrote: > On 13/06/2023 10:30 am, Jan Beulich wrote: >> On 12.06.2023 18:13, Andrew Cooper wrote: >>> @@ -593,15 +596,93 @@ static bool __init retpoline_calculations(void) >>> return false; >>> >>> /* >>> - * RSBA may be set by a hypervisor to

Re: [XEN v8 5/5] xen/arm: p2m: Enable support for 32bit IPA for ARM_32

On 02/06/2023 14:07, Ayan Kumar Halder wrote: > > > Refer ARM DDI 0406C.d ID040418, B3-1345, > > "A stage 2 translation with an input address range of 31-34 bits can > start the translation either: > > - With a first-level lookup, accessing a first-level translation > table with 2-16

Re: [XEN v8 1/5] xen/arm: p2m: Use the pa_range_info table to support ARM_32 and ARM_64

Hi Ayan, On 02/06/2023 14:07, Ayan Kumar Halder wrote: > > > Restructure the code so that one can use pa_range_info[] table for both > ARM_32 as well as ARM_64. I grepped for ARM_{32,64} in our code base and could not find any use in source files except for things introduced by this commit.

Re: [PATCH v4 04/34] pgtable: Create struct ptdesc

On Mon, 12 Jun 2023, Vishal Moola (Oracle) wrote: > Currently, page table information is stored within struct page. As part > of simplifying struct page, create struct ptdesc for page table > information. > > Signed-off-by: Vishal Moola (Oracle) Vishal, as I think you have already guessed,

Re: Functions _spin_lock_cb() and handle_ro_raz()

On 14/06/23 19:59, Julien Grall wrote: (+ Bertrand and Stefano) On 14/06/2023 14:08, Federico Serafini wrote: Hello everyone, Hi Federico, Let me start with a tip to help reaching the maintainers and getting a more timely answer. Xen-devel has a large volume of e-mails (still less than

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

On 2023/6/9 00:41, Robert Beckett wrote: > > On 08/06/2023 03:56, Jiqian Chen wrote: >> After suspending and resuming guest VM, you will get >> a black screen, and the display can't come back. >> >> This is because when guest did suspending, it called >> into qemu to call virtio_gpu_gl_reset. In

Re: [QEMU PATCH 1/1] virtgpu: do not destroy resources when guest suspend

Hi Marc-André Lureau On 2023/6/12 20:42, Marc-André Lureau wrote: > Hi > > On Thu, Jun 8, 2023 at 6:26 AM Jiqian Chen > wrote: > > After suspending and resuming guest VM, you will get > a black screen, and the display can't come back. > > This is

[xen-unstable test] 181431: tolerable FAIL - PUSHED

flight 181431 xen-unstable real [real] flight 181439 xen-unstable real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/181431/ http://logs.test-lab.xenproject.org/osstest/logs/181439/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking):

Re: [PATCH v3 2/4] xen: Add files needed for minimal ppc64le build

On 14.06.2023 18:36, Shawn Anastasio wrote: > On Wed Jun 14, 2023 at 10:51 AM CDT, Jan Beulich wrote: >> On 13.06.2023 16:50, Shawn Anastasio wrote: >>> +DECL_SECTION(.bss) { /* BSS */ >>> +__bss_start = .; >>> +*(.bss.stack_aligned) >>> +. =

Re: [PATCH 1/4] xen/arm: debug-pl011: Use correct accessors

Hi Stefano, On 15/06/2023 03:36, Stefano Stabellini wrote: > > > On Wed, 7 Jun 2023, Michal Orzel wrote: >> Although most PL011 UARTs can cope with 32-bit accesses, some of the old >> legacy ones might not. PL011 registers are 8/16-bit wide and this shall >> be perceived as the normal behavior.