On 16.06.2023 16:18, Roger Pau Monné wrote:
> On Thu, Jun 15, 2023 at 04:56:22PM +0200, Jan Beulich wrote:
>> 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 t
On 16.06.2023 17:54, Roberto Bagnara wrote:
> On 16/06/23 01:26, Stefano Stabellini wrote:
>> On Thu, 15 Jun 2023, Roberto Bagnara wrote:
>>> + see the documentation for -Wreturn-type in Section "3.8 Options
>>> to Request or Suppress Warnings" of GCC_MANUAL.
>>> + use of GNU statem
On 16.06.2023 22:39, Julien Grall wrote:
> On 16/06/2023 21:24, Andrew Cooper wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/ppc/ppc64/head.S
>>> @@ -0,0 +1,27 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>>> +
>>> +.section .text.header, "ax", %progbits
>>> +
>>> +ENTRY(start)
>>> +/*
On 16.06.2023 22:27, Andrew Cooper wrote:
> On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
>> diff --git a/xen/arch/ppc/ppc64/head.S b/xen/arch/ppc/ppc64/head.S
>> new file mode 100644
>> index 00..0b289c713a
>> --- /dev/null
>> +++ b/xen/arch/ppc/ppc64/head.S
>> @@ -0,0 +1,27 @@
>> +/* SPDX
On 16.06.2023 20:23, Andrew Cooper wrote:
> The asm forming early error handling is a mix of local and non-local symbols,
> and has some pointless comments. Drop the "# Error message" comments,
> tweaking the style on modified lines, and make the symbols local.
>
> However, leave behind one real
On 15.06.2023 17:31, Alejandro Vallejo wrote:
> 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
On 16.06.2023 22:56, Stefano Stabellini wrote:
> On Fri, 16 Jun 2023, Nicola Vetrini wrote:
>> On 16/06/23 09:19, Jan Beulich wrote:
>>> On 15.06.2023 18:39, nicola wrote:
while investigating possible patches regarding Mandatory Rule 9.1, I
found the following pattern, that is likely to r
On 19/06/2023 09:18, Jan Beulich wrote:
On 16.06.2023 22:56, Stefano Stabellini wrote:
On Fri, 16 Jun 2023, Nicola Vetrini wrote:
On 16/06/23 09:19, Jan Beulich wrote:
On 15.06.2023 18:39, nicola wrote:
while investigating possible patches regarding Mandatory Rule 9.1, I
found the followin
flight 181497 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
test-armhf-armhf-xl-vhd
> On 19 Jun 2023, at 09:23, Julien Grall wrote:
>
>
>
> On 19/06/2023 09:18, Jan Beulich wrote:
>> On 16.06.2023 22:56, Stefano Stabellini wrote:
>>> On Fri, 16 Jun 2023, Nicola Vetrini wrote:
On 16/06/23 09:19, Jan Beulich wrote:
> On 15.06.2023 18:39, nicola wrote:
>> while inv
On 19/06/2023 09:31, Luca Fancellu wrote:
On 19 Jun 2023, at 09:23, Julien Grall wrote:
On 19/06/2023 09:18, Jan Beulich wrote:
On 16.06.2023 22:56, Stefano Stabellini wrote:
On Fri, 16 Jun 2023, Nicola Vetrini wrote:
On 16/06/23 09:19, Jan Beulich wrote:
On 15.06.2023 18:39, nicola
> On 19 Jun 2023, at 09:50, Julien Grall wrote:
>
>
>
> On 19/06/2023 09:31, Luca Fancellu wrote:
>>> On 19 Jun 2023, at 09:23, Julien Grall wrote:
>>>
>>>
>>>
>>> On 19/06/2023 09:18, Jan Beulich wrote:
On 16.06.2023 22:56, Stefano Stabellini wrote:
> On Fri, 16 Jun 2023, Nicola
Since QEMU commit 74a1b256d775 ("configure: Bump minimum Clang version
to 10.0"), or QEMU v8.0, Clang 10.0 is now the minimum to build QEMU.
QEMU 8.0 fails to build on Ubuntu Bionic.
Signed-off-by: Anthony PERARD
---
Notes:
I've tested that change here, with QEMU v8.0.2:
https://gitlab.
Any comments? I'd really like to finish this off this merge window..
flight 181500 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181500/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-ins
In the files `xen/arch/arm/include/asm/arm(32|64)/flushtlb.h' there are a
few occurrences of nested '//' character sequences inside C-style comment
blocks, which violate Rule 3.1. The patch aims to resolve those by removing
the nested comments.
Signed-off-by: Nicola Vetrini
---
xen/arch/arm/incl
Hi all,
This patch series is about the violations present in the Xen sources of
Rule 3.1 from MISRA C:2012, whose headline states:
"The character sequences '/*' and '//' shall not be used within a comment".
In the context of the effort to bring xen into compliance w.r.t.
MISRA C:2012, and Rule 3.
In the file `xen/drivers/passthrough/arm/smmu-v3.c' there are a few occurrences
of nested '//' character sequences inside C-style comment blocks, which violate
Rule 3.1. The patch aims to resolve those by removing the nested comments.
Signed-off-by: Nicola Vetrini
---
xen/drivers/passthrough/arm
In the files modified by this patch there are a few occurrences of nested '//'
character sequences inside C-style comment blocks, which violate Rule 3.1.
The patch aims to resolve those by removing the nested comments.
In the file `xen/common/xmalloc_tlsf.c' the comment has been deleted,
following
Hi,
On 19/06/2023 10:56, Nicola Vetrini wrote:
In the files `xen/arch/arm/include/asm/arm(32|64)/flushtlb.h' there are a
few occurrences of nested '//' character sequences inside C-style comment
blocks, which violate Rule 3.1. The patch aims to resolve those by removing
the nested comments.
As
Hi,
On 19/06/2023 10:56, Nicola Vetrini wrote:
In the file `xen/drivers/passthrough/arm/smmu-v3.c' there are a few occurrences
of nested '//' character sequences inside C-style comment blocks, which violate
Rule 3.1. The patch aims to resolve those by removing the nested comments.
I think it i
Fri, 16 Jun 2023 15:22:24 +0100 George Dunlap :
> I agree; the clear implication is that with smt=0, you might have
> num_online_cpus() return 4, but cpuids that look like {1, 3, 5, 7}; so you
> need the trace buffer array to be of size 8.
I have tested the patch below with this cmdline:
conring_
Fri, 16 Jun 2023 17:08:25 +0100 Andrew Cooper :
> XENMEM_acquire_resource is a new mapping interface with far more sane
> semantics which, amongst other things, will work in PVH guests too.
Does that indicate xentrace will not work in a PVH dom0?
I will have a look how XENMEM_acquire_resource is
On 19.06.2023 12:13, Olaf Hering wrote:
> Regarding coding style: can this_cpu and per_cpu be used as array index,
> or is a temporary variable required? This would affect the number of
> lines changed in next_record.
I see no reason why it shouldn't be possible to be used. At least as
long as ove
On 19.06.2023 12:01, Julien Grall wrote:
> On 19/06/2023 10:56, Nicola Vetrini wrote:
>> In the files `xen/arch/arm/include/asm/arm(32|64)/flushtlb.h' there are a
>> few occurrences of nested '//' character sequences inside C-style comment
>> blocks, which violate Rule 3.1. The patch aims to resolv
On 19.06.2023 11:56, Nicola Vetrini wrote:
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -140,9 +140,6 @@ static inline void MAPPING_SEARCH(unsigned long *r, int
> *fl, int *sl)
> *fl = flsl(*r) - 1;
> *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
>
Hi,
On 19/06/2023 11:25, Jan Beulich wrote:
On 19.06.2023 12:01, Julien Grall wrote:
On 19/06/2023 10:56, Nicola Vetrini wrote:
In the files `xen/arch/arm/include/asm/arm(32|64)/flushtlb.h' there are a
few occurrences of nested '//' character sequences inside C-style comment
blocks, which viol
On 19/06/23 09:54, Jan Beulich wrote:
On 16.06.2023 17:54, Roberto Bagnara wrote:
On 16/06/23 01:26, Stefano Stabellini wrote:
On Thu, 15 Jun 2023, Roberto Bagnara wrote:
+ static function is used in an inline function with external linkage:
+ non-documented GCC extension.
I a
On 19/06/2023 10:09 am, Anthony PERARD wrote:
> Since QEMU commit 74a1b256d775 ("configure: Bump minimum Clang version
> to 10.0"), or QEMU v8.0, Clang 10.0 is now the minimum to build QEMU.
>
> QEMU 8.0 fails to build on Ubuntu Bionic.
>
> Signed-off-by: Anthony PERARD
Lovely...
Acked-by: Andre
On 19/06/2023 11:16 am, Olaf Hering wrote:
> Fri, 16 Jun 2023 17:08:25 +0100 Andrew Cooper :
>
>> XENMEM_acquire_resource is a new mapping interface with far more sane
>> semantics which, amongst other things, will work in PVH guests too.
> Does that indicate xentrace will not work in a PVH dom0?
On 19/06/2023 9:10 am, Jan Beulich wrote:
> On 16.06.2023 20:23, Andrew Cooper wrote:
>> The asm forming early error handling is a mix of local and non-local symbols,
>> and has some pointless comments. Drop the "# Error message" comments,
>> tweaking the style on modified lines, and make the symb
On Sun, Jun 18, 2023 at 06:22:01PM -0400, Joel Upham wrote:
> Q35 support using Qemu's device emulation. I based the patches from 2017
> found on the mailing list here:
> https://lists.xenproject.org/archives/html/xen-devel/2018-03/msg01176.html
>
> I have been using a version of these patches on
On 14.06.2023 20:02, Jason Andryuk wrote:
> Falling back from cpufreq=hwp to cpufreq=xen is a more user-friendly
> choice than disabling cpufreq when HWP is not available. Specifying
> cpufreq=hwp indicates the user wants cpufreq, so, if HWP isn't
> available, it makes sense to give them the cpufr
On 19.06.2023 13:20, Andrew Cooper wrote:
> On 19/06/2023 9:10 am, Jan Beulich wrote:
>> On 16.06.2023 20:23, Andrew Cooper wrote:
>>> The asm forming early error handling is a mix of local and non-local
>>> symbols,
>>> and has some pointless comments. Drop the "# Error message" comments,
>>> tw
On 19.06.2023 12:53, Roberto Bagnara wrote:
> On 19/06/23 09:54, Jan Beulich wrote:
>> On 16.06.2023 17:54, Roberto Bagnara wrote:
>>> On 16/06/23 01:26, Stefano Stabellini wrote:
On Thu, 15 Jun 2023, Roberto Bagnara wrote:
> + static function is used in an inline function with exter
On 14.06.2023 20:02, Jason Andryuk wrote:
> When using HWP, some of the returned data is not applicable. In that
> case, we should just omit it to avoid confusing the user. So switch to
> printing the base and max frequencies since those are relevant to HWP.
> Similarly, stop printing the CPU fre
There are just two callers of this function. It is identical to the
checks done in __trace_var.
The commit message of 9a86ac1aa3d2ebe1be05dc7fe78dd6759aa3241d
("xentrace 5/7: Additional tracing for the shadow code.") gives no
indication what the benefit of this function is.
Signed-off-by: Olaf Her
On 24.04.2023 10:20, Xenia Ragiadakou wrote:
> This patch series aims to make the msr intercept handling, performed in
> vpmu code, virtualization technology agnostic.
> It creates a common interface for setting/clearing the msr intercepts and
> then add hooks to the corresponding hvm_funcs table t
Hi,
> Adding a new command requires new feature flag (and maybe it should be in
> the <0x1000 range instead)
>
> But I am not sure we need a new message at the virtio-gpu level. Gerd, wdyt?
>
> Maybe it's not a good place to reset all GPU resources during QEMU reset()
> after all, if it's call
On 19.06.2023 14:18, Olaf Hering wrote:
> There are just two callers of this function. It is identical to the
> checks done in __trace_var.
But it's used differently.
> The commit message of 9a86ac1aa3d2ebe1be05dc7fe78dd6759aa3241d
> ("xentrace 5/7: Additional tracing for the shadow code.") gives
On 19/06/2023 1:18 pm, Olaf Hering wrote:
> There are just two callers of this function. It is identical to the
> checks done in __trace_var.
> The commit message of 9a86ac1aa3d2ebe1be05dc7fe78dd6759aa3241d
> ("xentrace 5/7: Additional tracing for the shadow code.") gives no
> indication what the b
On Tue, Jun 13, 2023 at 08:45:31AM +0200, Juergen Gross wrote:
> On 12.06.23 22:09, Demi Marie Obenour wrote:
> > On Mon, Jun 12, 2023 at 08:27:59AM +0200, Juergen Gross wrote:
> > > On 10.06.23 17:32, Demi Marie Obenour wrote:
> > > > When a grant entry is still in use by the remote domain, Linux
The reason for reset_stack() introduction is that stack should be
reset twice:
1. Before jumping to C world at the start of _start() function.
2. After jumping from 1:1 mapping world.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
---
Changes in V2:
- update the commit message.
The function was introduced to calculate and save physical
offset before MMU is enabled because access to start() is
PC-relative and in case of linker_addr != load_addr it will
result in incorrect value in phys_offset.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- add __ro_after_init for
Sometimes variables are located in .sbss section but it won't
be mapped after MMU will be enabled.
To avoid MMU failures .sbss should be mapped
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
---
Changes in V2:
- add .sbss.*.
- move .sbss* ahead of .bss*.
- add Acked-by: Alistai
Signed-off-by: Oleksii Kurochko
Suggested-by: Andrew Cooper
---
Changes in V2:
- change SPDX tags from GPL-2.0-or-later to GPL-2.0-only.
- add Suggested-by: Andrew Cooper .
---
xen/arch/riscv/include/asm/current.h | 2 ++
xen/arch/riscv/include/asm/early_printk.h | 2 ++
xen/arch/riscv/
The way how switch to virtual address was implemented in the
commit e66003e7be ("xen/riscv: introduce setup_initial_pages")
isn't safe enough as:
* enable_mmu() depends on hooking all exceptions
and pagefault.
* Any exception other than pagefault, or not taking a pagefault
causes it to malfunct
Signed-off-by: Oleksii Kurochko
Suggested-by: Andrew Cooper
---
Changes in V2:
- add Suggested-by: Andrew Cooper .
---
xen/arch/riscv/include/asm/mm.h | 2 ++
xen/arch/riscv/mm.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/riscv/include/asm/mm.h
The patch series introduces things necessary to implement identity mapping:
1. Make identity mapping for the entire Xen.
2. Enable MMU.
3. Jump to the virtual address world
4. Remove identity mapping.
Also current patch series introduces the calculation of physical offset before
MMU is ena
On 19/06/23 09:54, Jan Beulich wrote:
On 16.06.2023 17:54, Roberto Bagnara wrote:
On 16/06/23 01:26, Stefano Stabellini wrote:
On Thu, 15 Jun 2023, Roberto Bagnara wrote:
+ * - Unspecified escape sequence is encountered in a character constant or a
string literal token
+ - X86_64
+
On 14.06.2023 20:02, Jason Andryuk wrote:
> --- a/xen/arch/x86/acpi/cpufreq/hwp.c
> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c
> @@ -537,6 +537,29 @@ static const struct cpufreq_driver __initconstrel
> hwp_cpufreq_driver =
> .update = hwp_cpufreq_update,
> };
>
> +int get_hwp_para(const unsigne
flight 181498 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt broken
test-armhf-armhf-xl
On 14.06.2023 20:02, Jason Andryuk wrote:
> Print HWP-specific parameters. Some are always present, but others
> depend on hardware support.
>
> Signed-off-by: Jason Andryuk
Reviewed-by: Jan Beulich
On 14.06.2023 20:02, Jason Andryuk wrote:
> +static void cppc_set_func(int argc, char *argv[])
> +{
> +xc_set_cppc_para_t set_cppc = {};
> +int cpuid = -1;
> +int i = 0;
While cpuid needs to remain of signed type, i wants to be unsigned int.
> +if ( parse_cppc_opts(&set_cppc, &cpu
On 15.06.2023 18:27, Alejandro Vallejo wrote:
> --- a/xen/common/pdx.c
> +++ b/xen/common/pdx.c
> @@ -20,13 +20,55 @@
> #include
> #include
>
> -/* Parameters for PFN/MADDR compression. */
> +/*
> + * Diagram to make sense of the following variables. The masks and shifts
> + * are done on mfn
On 15.06.2023 17:48, Alejandro Vallejo wrote:
> 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 i
On 15.06.2023 17:48, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/cpu/microcode/amd.c
> +++ b/xen/arch/x86/cpu/microcode/amd.c
> @@ -432,9 +432,13 @@ static struct microcode_patch *cf_check
> cpu_request_microcode(
> return patch;
> }
>
> -const struct microcode_ops __initconst_cf_clobber
On 15.06.2023 17:48, Alejandro Vallejo wrote:
> 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
Reviewed-by: Jan Beulich
Aiui this is independent of patch 2
On 15/06/2023 4:48 pm, Alejandro Vallejo wrote:
> diff --git a/xen/arch/x86/cpu/microcode/core.c
> b/xen/arch/x86/cpu/microcode/core.c
> index e65af4b82e..df7e1df870 100644
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -750,11 +750,12 @@ __initcall(microc
On 6/16/23 3:24 PM, Andrew Cooper wrote:
> On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
>> Add the build system changes required to build for ppc64le (POWER8+).
>> As of now the resulting image simply boots to an infinite loop.
>>
>> $ make XEN_TARGET_ARCH=ppc64 -C xen openpower_defconfig
>> $ mak
On 15.06.2023 17:48, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -879,5 +879,18 @@ int __init early_microcode_init(unsigned long
> *module_map,
> if ( ucode_mod.mod_end || ucode_blob.size )
> rc = early_microcode_u
On 19.06.2023 17:49, Andrew Cooper wrote:
> On 15/06/2023 4:48 pm, Alejandro Vallejo wrote:
>> diff --git a/xen/arch/x86/cpu/microcode/core.c
>> b/xen/arch/x86/cpu/microcode/core.c
>> index e65af4b82e..df7e1df870 100644
>> --- a/xen/arch/x86/cpu/microcode/core.c
>> +++ b/xen/arch/x86/cpu/microcode
On 19.06.2023 17:49, Shawn Anastasio wrote:
> On 6/16/23 3:24 PM, Andrew Cooper wrote:
>> On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
>>> Add the build system changes required to build for ppc64le (POWER8+).
>>> As of now the resulting image simply boots to an infinite loop.
>>>
>>> $ make XEN_TA
On 19/06/2023 4:58 pm, Jan Beulich wrote:
> On 19.06.2023 17:49, Andrew Cooper wrote:
>> On 15/06/2023 4:48 pm, Alejandro Vallejo wrote:
>>> diff --git a/xen/arch/x86/cpu/microcode/core.c
>>> b/xen/arch/x86/cpu/microcode/core.c
>>> index e65af4b82e..df7e1df870 100644
>>> --- a/xen/arch/x86/cpu/mic
On 19.06.2023 18:06, Andrew Cooper wrote:
> On 19/06/2023 4:58 pm, Jan Beulich wrote:
>> On 19.06.2023 17:49, Andrew Cooper wrote:
>>> On 15/06/2023 4:48 pm, Alejandro Vallejo wrote:
diff --git a/xen/arch/x86/cpu/microcode/core.c
b/xen/arch/x86/cpu/microcode/core.c
index e65af4b82e.
On 19/06/2023 4:49 pm, Shawn Anastasio wrote:
> On 6/16/23 3:24 PM, Andrew Cooper wrote:
>> On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
>>> Add the build system changes required to build for ppc64le (POWER8+).
>>> As of now the resulting image simply boots to an infinite loop.
>>>
>>> $ make XEN_
On 6/19/23 11:07 AM, Jan Beulich wrote:
>> It seems like the build system expects an `$(ARCH)_defconfig` present if
>> you don't manually specify a defconfig target. I see riscv64 has a
>> tiny64_defconfig and a riscv64_defconfig that are idential, probably for
>> this same reason. Would you like m
Hi,
On 19/06/2023 17:25, Andrew Cooper wrote:
On 19/06/2023 4:49 pm, Shawn Anastasio wrote:
On 6/16/23 3:24 PM, Andrew Cooper wrote:
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
Add the build system changes required to build for ppc64le (POWER8+).
As of now the resulting image simply boots t
From: Julien Grall
Hi all,
The main goal of this series is to add some missing ISBs after update
the PTEs.
The last patch is re-ingesting a patch that was reverted
due to a boot failure on the Arndale. This has now been fixed by patch
#2.
Cheers,
Julien Grall (7):
xen/arm32: head: Add missi
From: Julien Grall
Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused
From: Julien Grall
Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruction
fetches or accesses caused
From: Julien Grall
The implementation of write_pte() is pretty much the same on arm32
and arm64. So it would be good to consolidate it as this would help
to clarify the requirements when using the helper.
Take the opportunity to switch from assembly to call macros. Note there
is a difference on
From: Julien Grall
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruc
From: Julien Grall
On older version of the Arm Arm (ARM DDI 0487E.a, B2-125) there were
the following paragraph:
"DMB and DSB instructions affect reads and writes to the memory system
generated by Load/Store instructions and data or unified cache
maintenance instructions being executed by the PE
From: Julien Grall
At the moment, the temporary mapping is only used when the virtual
runtime region of Xen is clashing with the physical region.
In follow-up patches, we will rework how secondary CPU bring-up works
and it will be convenient to use the fixmap area for accessing
the root page-tab
From: Julien Grall
Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
"The DMB and DSB memory barriers affect reads and writes to the memory
system generated by load/store instructions and data or unified cache
maintenance operations being executed by the processor. Instruc
flight 181504 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181504/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
flight 181499 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181499/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-install
Hi Juergen,
On 30/05/2023 09:54, Juergen Gross wrote:
-static struct live_update *lu_status;
-
-struct lu_dump_state {
- void *buf;
- unsigned int size;
-#ifndef __MINIOS__
- int fd;
- char *filename;
-#endif
-};
-
-static int lu_destroy(void *data)
-{
-#ifdef __MINIOS__
Hi Juergen,
On 30/05/2023 09:54, Juergen Gross wrote:
Move the rest of live update related code from xenstored_control.c to
a dedicated new source file.
Signed-off-by: Juergen Gross
Depending on the outcome of the discussion in patch #15, this patch may
need to be updated. At its current st
Hi Juergen,
On 30/05/2023 09:54, Juergen Gross wrote:
Remove the hlist defines/functions and the rcu related functions from
tools/xenstore/list.h, as they are not used.
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
Cheers,
--
Julien Grall
These aren't used, and are not obvious useful either.
tools/ does have some logic which works on $(XEN_OS) directly, and some on
CONFIG_$(XEN_OS) too, but this isn't how we typically refer to things.
The only user ever of this scheme was introduced in c0fd920e987 (2006) and
deleted in fa2244104b4
Hi Juergen,
I haven't looked at the code in details yet. But I have a few questions
regarding the commit message/
On 30/05/2023 10:13, Juergen Gross wrote:
Today all Xenstore nodes are stored in a TDB data base. This data base
has several disadvantages:
- it is using a fixed sized hash table
Hi Juergen,
On 30/05/2023 10:13, Juergen Gross wrote:
Instead of using TDB_REPLACE for either creating or modifying a TDB
entry, use either TDB_INSERT or TDB_MODIFY when calling tdb_store().
At higher function levels use the abstract flag values NODE_CREATE
and NODE_MODIFY.
This is for prepari
flight 181503 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-ins
On Mon, 19 Jun 2023, Anthony PERARD wrote:
> Since QEMU commit 74a1b256d775 ("configure: Bump minimum Clang version
> to 10.0"), or QEMU v8.0, Clang 10.0 is now the minimum to build QEMU.
>
> QEMU 8.0 fails to build on Ubuntu Bionic.
>
> Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellin
I actually realized that after submitting yesterday and have been splitting
them like the original had done for both Qemu and Xen. Thanks again for
getting back to me.
-Joel
On Mon, Jun 19, 2023 at 7:22 AM Roger Pau Monné
wrote:
> On Sun, Jun 18, 2023 at 06:22:01PM -0400, Joel Upham wrote:
> >
flight 181502 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181502/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
flight 181510 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181510/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 host-ins
flight 181509 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181509/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
Hi Julien,
> -Original Message-
> Subject: [PATCH 1/7] xen/arm32: head: Add missing isb in setup_fixmap()
>
> From: Julien Grall
>
> Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
>
> "The DMB and DSB memory barriers affect reads and writes to the memory
> system generated by load/store ins
Hi Julien,
> -Original Message-
> Subject: [PATCH 3/7] xen/arm64: head: Add missing isb in setup_fixmap()
>
> From: Julien Grall
>
> On older version of the Arm Arm (ARM DDI 0487E.a, B2-125) there were
> the following paragraph:
>
> "DMB and DSB instructions affect reads and writes to
Hi Julien,
> -Original Message-
> Subject: [PATCH 4/7] xen/arm: page: Consolidate write_pte() and clarify the
> documentation
>
> From: Julien Grall
>
> The implementation of write_pte() is pretty much the same on arm32
> and arm64. So it would be good to consolidate it as this would he
Hi Julien,
> -Original Message-
> Subject: [PATCH 2/7] xen/arm32: head: Add mising isb in
> switch_to_runtime_mapping()
>
> From: Julien Grall
>
> Per the Arm Arm (ARM DDI 0406C.d A3.8.3):
>
> "The DMB and DSB memory barriers affect reads and writes to the memory
> system generated by
Hi Julien,
> -Original Message-
> Subject: [PATCH 7/7] xen/arm32: head: Widen the use of the temporary
> mapping
>
> From: Julien Grall
>
> At the moment, the temporary mapping is only used when the virtual
> runtime region of Xen is clashing with the physical region.
>
> In follow-up
Hi Julien,
> -Original Message-
> Subject: [PATCH 5/7] xen/arm: pmap: Add missing ISB in arch_pmap_map()
>
> From: Julien Grall
>
> Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
>
> "The DMB and DSB memory barriers affect reads and writes to the memory
> syst
Hi Julien,
> -Original Message-
> Subject: [PATCH 6/7] xen/arm: mm: Add missing ISB in xen_pt_update()
>
> From: Julien Grall
>
> Per the Arm Arm, (Armv7 DDI406C.d A3.8.3 and Armv8 DDI 0487J.a B2.3.12):
>
> "The DMB and DSB memory barriers affect reads and writes to the memory
> system
flight 181508 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181508/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf
On 19.06.2023 18:29, Shawn Anastasio wrote:
> On 6/19/23 11:07 AM, Jan Beulich wrote:
>>> Good point. Following the example in the Power ELFv2 ABI
>>> specification [1] for function type annotation, I'll place
>>>
>>> .type start, @function
>>>
>>> in the ENTRY macro. It's not clear what the differ
On 19.06.2023 18:44, Julien Grall wrote:
> Hi,
>
> On 19/06/2023 17:25, Andrew Cooper wrote:
>> On 19/06/2023 4:49 pm, Shawn Anastasio wrote:
>>> On 6/16/23 3:24 PM, Andrew Cooper wrote:
On 16/06/2023 6:48 pm, Shawn Anastasio wrote:
> Add the build system changes required to build for ppc
100 matches
Mail list logo
