On Fri, 20 Dec 2024 17:26:38 +0800 Guo Weikang
wrote:
> Before SLUB initialization, various subsystems used memblock_alloc to
> allocate memory. In most cases, when memory allocation fails, an immediate
> panic is required. To simplify this behavior and reduce repetitive checks,
> introduce `mem
AMD have updated the SRSO whitepaper[1] with further information. These
features exist on AMD Zen5 CPUs and are necessary for Xen to use.
The two features are in principle unrelated:
* SRSO_U/S_NO is an enumeration saying that SRSO attacks can't cross the
User(CPL3) / Supervisor(CPL<3) bound
On 20/12/2024 6:51 pm, Shawn Anastasio wrote:
> Hi Andrew,
>
> On 12/20/24 12:23 PM, Andrew Cooper wrote:
>> On 20/12/2024 5:53 pm, Shawn Anastasio wrote:
>>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>>>
Hi Andrew,
On 12/20/24 12:23 PM, Andrew Cooper wrote:
> On 20/12/2024 5:53 pm, Shawn Anastasio wrote:
>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>> represent architecture-dependent page table entry flags
On 20/12/2024 5:53 pm, Shawn Anastasio wrote:
> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
> represent architecture-dependent page table entry flags. This assumption
> does not work on PPC/radix where some fl
Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
represent architecture-dependent page table entry flags. This assumption
does not work on PPC/radix where some flags go past 32-bits, so update
these APIs to use unsig
Default switch case exits directly; these instructions are never reached.
The file was taken from Linux; the copies have diverged a lot since:
```
$ diff -u xen/xen/tools/kconfig/expr.c linux/scripts/kconfig/expr.c | wc -l
984
```
Therefore the change is only applied locally.
Coverity-ID: 14580
Hello,
This series addresses the Coverity IDs 1056148, 1056149, & 1458052.
Thank you,
Ariel Otilibili (2):
tools/libs: remove dead code
xen/tools: remove dead code
tools/libs/light/libxl_create.c | 1 -
tools/libs/light/libxl_device.c | 1 -
xen/tools/kconfig/expr.c| 2 --
3 files
Default switch cases skip these steps; these instructions are never reached.
Coverity-IDs: 1056148, 1056149
Fixes: 0a69ea908d ("libxl: ao: convert libxl__spawn_*")
Fixes: 643b106b40 ("libxl: do not use tap disk backend other than for raw and
vhd")
Signed-off-by: Ariel Otilibili
--
Cc: Anthony PE
On Fri, Dec 20, 2024 at 2:09 PM Jan Beulich wrote:
>
> To avoid the flag becoming "sticky", I think you need to clear it ahead of
> this switch() (or right at the start of the function).
>
> Jan
When thinking about it now, wouldn't it make sense to only reset it in
the p2m_ram_rw case above? I me
On 2024-12-20 08:00, Jan Beulich wrote:
On 19.12.2024 23:32, Jason Andryuk wrote:
--- a/xen/include/public/io/console.h
+++ b/xen/include/public/io/console.h
@@ -19,6 +19,19 @@ struct xencons_interface {
char out[2048];
XENCONS_RING_IDX in_cons, in_prod;
XENCONS_RING_IDX out_co
Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges") introduced a type in the 'struct membanks_hdr'
but forgot to update the 'struct kernel_info' initialiser, while
it doesn't lead to failures because the field is not currently
used while managing kernel_info s
Hi,
On 20/12/2024 09:32, Michal Orzel wrote:
>
> On 19/12/2024 12:23, Andrei Cherechesu (OSS) wrote:
>>
>> From: Andrei Cherechesu
>>
>> Targeting: Xen 4.20
>> This v4 version of this patch series finishes the work left to support NXP
>> S32G3 Processors [0], part of the NXP S32CC Family. The LI
On 20.12.2024 00:55, Petr Beneš wrote:
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -176,6 +176,10 @@ static void ept_p2m_type_to_flags(const struct
> p2m_domain *p2m,
> break;
> case p2m_access_rwx:
> break;
> +case
On 19.12.2024 23:32, Jason Andryuk wrote:
> --- a/xen/include/public/io/console.h
> +++ b/xen/include/public/io/console.h
> @@ -19,6 +19,19 @@ struct xencons_interface {
> char out[2048];
> XENCONS_RING_IDX in_cons, in_prod;
> XENCONS_RING_IDX out_cons, out_prod;
> +/*
> + * Flag val
On Friday, December 20, 2024 10:01 CET, "Ariel Otilibili-Anieli"
wrote:
> On Friday, December 20, 2024 09:53 CET, Greg KH
> wrote:
>
> > On Fri, Dec 20, 2024 at 09:44:31AM +0100, Ariel Otilibili-Anieli wrote:
> > > On Friday, December 20, 2024 08:09 CET, Greg KH
> > > wrote:
> > >
> > > >
Return false from arch_vcpu_ioreq_completion() when completion is not handled.
According to coding-best-practices.pandoc an error should be propagated to
caller, if caller is expecting to handle it, which seems to the case for
callers of arch_vcpu_ioreq_completion().
Suggested-by: Jan Beulich
Sig
On Friday, December 20, 2024 09:49 CET, Luca Fancellu
wrote:
> Hi Ariel,
>
> > On 19 Dec 2024, at 18:10, Ariel Otilibili
> > wrote:
> >
> > Same fix than commit 826a9eb072 (tools: Fix regex syntax warnings with
> > Python 3.12).
> >
> > It clears out the warning:
> >
> > ```
> > $ xen/scr
On Friday, December 20, 2024 09:53 CET, Greg KH
wrote:
> On Fri, Dec 20, 2024 at 09:44:31AM +0100, Ariel Otilibili-Anieli wrote:
> > On Friday, December 20, 2024 08:09 CET, Greg KH
> > wrote:
> >
> > > On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
> > > > This is a follow u
On Fri, Dec 20, 2024 at 09:44:31AM +0100, Ariel Otilibili-Anieli wrote:
> On Friday, December 20, 2024 08:09 CET, Greg KH
> wrote:
>
> > On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
> > > This is a follow up from a discussion in Xen:
> > >
> > > The if-statement tests `res`
Hi Ariel,
> On 19 Dec 2024, at 18:10, Ariel Otilibili
> wrote:
>
> Same fix than commit 826a9eb072 (tools: Fix regex syntax warnings with Python
> 3.12).
>
> It clears out the warning:
>
> ```
> $ xen/scripts/xen-analysis.py
> xen/scripts/xen_analysis/cppcheck_analysis.py:94: SyntaxWarning:
On Friday, December 20, 2024 08:09 CET, Greg KH
wrote:
> On Thu, Dec 19, 2024 at 11:45:01PM +0100, Ariel Otilibili wrote:
> > This is a follow up from a discussion in Xen:
> >
> > The if-statement tests `res` is non-zero; meaning the case zero is never
> > reached.
> >
> > Link:
> > https://
On Fri, Dec 20, 2024 at 8:34 AM Michal Orzel wrote:
>
> On 17/12/2024 18:06, Carlo Nonato wrote:
> >
> > Shared caches in multi-core CPU architectures represent a problem for
> > predictability of memory access latency. This jeopardizes applicability
> > of many Arm platform in real-time critical
It's definitely worth mentioning as one of the most notable feature on
Arm this release.
Signed-off-by: Michal Orzel
---
CHANGELOG.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index fe6c4cf9432e..8507e6556a56 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -
On 12/20/24 9:19 AM, Michal Orzel wrote:
It's definitely worth mentioning as one of the most notable feature on
Arm this release.
Totally agree with that.
Acked-by: Oleksii Kurochko
Thanks.
~ Oleksii
Signed-off-by: Michal Orzel
---
CHANGELOG.md | 1 +
1 file changed, 1 insertion(
25 matches
Mail list logo
