flight 187405 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187405/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187390
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 187413 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187413/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6a7be5a8418ab6397375e32e399e9523db9d4293
baseline version:
ovmf b6c4708c4d3470cfd9f46
flight 187401 linux-linus real [real]
flight 187411 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187401/
http://logs.test-lab.xenproject.org/osstest/logs/187411/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On Thu, 29 Aug 2024, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Fixes: 95764a0817a5 (automation: update xilinx test scripts (tty))
> This patch introduced a CI failure due to a timeout in xilinx-x86_64 test.
>
> Change xilinx-x86_64 and xilinx-arm64 scripts to use "expect" utility
> to
On Thu, 29 Aug 2024, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Fix flaw in qemu-*.sh tests that producess a false success. The following
> lines produces success despite the "expect" script producing nonzero exit
> status:
>
> set +e
> ...
> ./automation/scripts/qemu-key.exp |
From: Victor Lira
Fix flaw in qemu-*.sh tests that producess a false success. The following
lines produces success despite the "expect" script producing nonzero exit
status:
set +e
...
./automation/scripts/qemu-key.exp | sed 's/\r\+$//'
(end of file)
The default exit status for a pi
From: Victor Lira
Fixes: 95764a0817a5 (automation: update xilinx test scripts (tty))
This patch introduced a CI failure due to a timeout in xilinx-x86_64 test.
Change xilinx-x86_64 and xilinx-arm64 scripts to use "expect" utility
to determine test result and allow early exit from tests.
Add "exp
From: Victor Lira
Separated into two patches to improve clarity and updated to use the
"pipefail" function instead of "mkfifo".
Victor Lira (2):
automation: fix qemu test false success
automation: use expect utility in xilinx tests
.../build/ubuntu/xenial-xilinx.dockerfile | 1 +
auto
flight 187409 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187409/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b6c4708c4d3470cfd9f465771a665510d3ad1a66
baseline version:
ovmf 1169122c6f22d4db3e44b
flight 187397 qemu-mainline real [real]
flight 187408 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187397/
http://logs.test-lab.xenproject.org/osstest/logs/187408/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Thu, 28 Aug 2024, Lira, Victor M wrote:
> Hello Michal,
>
> Unfortunately only removing "set +e" did not fix the issue as the test still
> will always pass.
> See here (line 90):
> https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/7700210695
>
> I think we will need to use the fifo
flight 187407 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187407/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1169122c6f22d4db3e44b7b720480522b6933a62
baseline version:
ovmf 01735bbe4a46a6fb7d5d7
On 16/08/2024 12:14 pm, Sergiy Kibrik wrote:
> Put platforms-specific code under #ifdef CONFIG_{AMD,INTEL} so that when
> corresponding CPU support is disabled by configuration less dead code will end
> up in the build.
>
> This includes re-ordering of calls to ibpb_calculations() &
> div_calculat
The user of cr4_pv32_mask (the cr4_pv32_restore() function) only exists in a
CONFIG_PV32 build, but right now the variable is unconditionally set up.
To start with, move the setup into set_in_cr4() and remove it from it's
somewhat ad-hoc position in __start_xen(). This means the variable will be
On 29/08/2024 5:08 pm, Jason Andryuk wrote:
> Hi Everyone,
>
> I've been looking at ioreq latency and pausing of vCPUs. Specifically
> for MMIO (IOREQ_TYPE_COPY) writes, they still need completions:
>
> static inline bool ioreq_needs_completion(const ioreq_t *ioreq)
> {
> return ioreq->state =
Hello Michal,
Unfortunately only removing "set +e" did not fix the issue as the test
still will always pass.
See here (line 90):
https://gitlab.com/xen-project/people/sstabellini/xen/-/jobs/7700210695
I think we will need to use the fifo or the Bash "pipefail" function.
You may want to use "
flight 187395 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187395/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187374
test-amd64-amd64-libvirt-xsm 15 migrate-s
Hi Everyone,
I've been looking at ioreq latency and pausing of vCPUs. Specifically
for MMIO (IOREQ_TYPE_COPY) writes, they still need completions:
static inline bool ioreq_needs_completion(const ioreq_t *ioreq)
{
return ioreq->state == STATE_IOREQ_READY &&
!ioreq->data_is_ptr &
On Fri, Aug 23, 2024 at 06:05:03PM +0100, Javi Merino wrote:
> When built with ASAN, "xl dmesg" crashes in the "printf("%s", line)"
> call in main_dmesg(). ASAN reports a heap buffer overflow: an
> off-by-one access to cr->buffer.
>
> The readconsole sysctl copies up to count characters into the
On Thu, Aug 29, 2024 at 01:15:42PM +, Anthony PERARD wrote:
> On Thu, Aug 29, 2024 at 12:59:43PM +0200, Roger Pau Monné wrote:
> > Hello,
> >
> > To give some context, this started as a bug report against FreeBSD failing
> > to
> > work with PV blkif attached disks with 4K logical sectors when
flight 187390 xen-unstable real [real]
flight 187404 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187390/
http://logs.test-lab.xenproject.org/osstest/logs/187404/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On 29.08.2024 16:42, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-08-29 at 14:14 +0200, Jan Beulich wrote:
>> Also note that "`mfn` is
>> valid" isn't the same as "mfn != INVALID_MFN". You want to be
>> precise
>> here,
>> to avoid confusion later on. (I say that knowing th
flight 187403 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187403/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 01735bbe4a46a6fb7d5d739d0fc5a14897ad18da
baseline version:
ovmf bb248a95091ab54244005
On Thu, 2024-08-29 at 14:14 +0200, Jan Beulich wrote:
> > > > > Also note that "`mfn` is
> > > > > valid" isn't the same as "mfn != INVALID_MFN". You want to be
> > > > > precise
> > > > > here,
> > > > > to avoid confusion later on. (I say that knowing that we're
> > > > > still
> > > > > fightin
On 29.08.2024 00:03, Andrew Cooper wrote:
> It has existed in x86 CPUs since 2008, so we're only 16 years late adding
> support. With all the other scafolding in place, implement arch_hweightl()
> for x86.
>
> The only complication is that the call to arch_generic_hweightl() is behind
> the compi
On 29.08.2024 00:03, Andrew Cooper wrote:
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -331,6 +331,14 @@ static always_inline attr_const unsigned int
> hweight32(uint32_t x)
> return hweightl(x);
> }
>
> +static always_inline attr_const unsigned int hweight64(uint
On 29.08.2024 00:03, Andrew Cooper wrote:
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -326,6 +326,11 @@ static always_inline attr_const unsigned int
> hweightl(unsigned long x)
> #endif
> }
>
> +static always_inline attr_const unsigned int hweight32(uint32_t x)
See
On 29.08.2024 00:03, Andrew Cooper wrote:
> There are 6 remaining callers in Xen:
>
> * The two hweight32() calls, _domain_struct_bits() and efi_find_gop_mode(),
> are __init only.
> * The two hweight_long() calls are both in bitmap_weight().
> * The two hweight64() calls are hv_vpset_nr
On 29.08.2024 00:03, Andrew Cooper wrote:
> All of the ffs()/fls() infrastructure is in fact (attr) const, because it
> doesn't even read global state. This allows the compiler even more
> flexibility to optimise.
>
> No functional change.
>
> Reported-by: Jan Beulich
> Signed-off-by: Andrew Co
On 29.08.2024 00:03, Andrew Cooper wrote:
> There's no need for the name to be so verbose.
>
> No functional change.
>
> Suggest-by: Jan Beulich
The form you use here was your suggestion, wasn't it? I'm fine with the
change as is, so ...
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulic
On Thu, Aug 29, 2024 at 1:07 PM Andrew Cooper wrote:
>
> On 29/08/2024 12:52 pm, Frediano Ziglio wrote:
> > diff --git a/xen/arch/x86/boot/defs.h b/xen/arch/x86/boot/defs.h
> > index 239b9f8716..ee1a4da6af 100644
> > --- a/xen/arch/x86/boot/defs.h
> > +++ b/xen/arch/x86/boot/defs.h
> > @@ -57,7 +5
From: Michal Orzel
Add the requirements for emulated SBSA UART.
Signed-off-by: Michal Orzel
Signed-off-by: Ayan Kumar Halder
---
.../fusa/reqs/design-reqs/arm64/sbsa-uart.rst | 224 ++
docs/fusa/reqs/market-reqs/reqs.rst | 31 +++
docs/fusa/reqs/product-reqs/arm64/r
On Thu, Aug 29, 2024 at 12:59:43PM +0200, Roger Pau Monné wrote:
> Hello,
>
> To give some context, this started as a bug report against FreeBSD failing to
> work with PV blkif attached disks with 4K logical sectors when the backend is
> Linux kernel blkback:
>
> https://bugs.freebsd.org/bugzilla/s
On 29.08.2024 14:51, Andrew Cooper wrote:
> On 29/08/2024 1:01 pm, Jan Beulich wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -66,10 +66,10 @@ struct cpu_time {
>> struct platform_timesource {
>> const char *id;
>> const char *name;
>> -u64 frequency;
>> +
On 29/08/2024 8:31 am, Roger Pau Monné wrote:
> On Wed, Aug 28, 2024 at 07:57:39PM +0100, Andrew Cooper wrote:
>> On 28/08/2024 2:02 pm, Roger Pau Monné wrote:
>>> On Wed, Aug 28, 2024 at 12:51:23PM +0100, Andrew Cooper wrote:
On 28/08/2024 12:50 pm, Jan Beulich wrote:
> On 28.08.2024 13:3
On 29.08.2024 14:44, Andrew Cooper wrote:
> On 29/08/2024 1:01 pm, Jan Beulich wrote:
>> ... and move the type itself to linux-compat.h.
>>
>> While doing so switch a few adjacent types as well, for (a little bit
>> of) consistency.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Andrew Cooper
On 29/08/2024 1:01 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -66,10 +66,10 @@ struct cpu_time {
> struct platform_timesource {
> const char *id;
> const char *name;
> -u64 frequency;
> +uint64_t frequency;
> /* Post-init this hook ma
flight 187400 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187400/
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
On 29/08/2024 1:01 pm, Jan Beulich wrote:
> ... and move the type itself to linux-compat.h.
>
> While doing so switch a few adjacent types as well, for (a little bit
> of) consistency.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , with a minor
formatting request.
> --- a/xen/arch/a
flight 187402 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187402/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bb248a95091ab542440053d9c289a97e80eb6630
baseline version:
ovmf 31f022500549f1d862af5
On 29/08/2024 1:00 pm, Jan Beulich wrote:
> ... and move the type itself to linux-compat.h.
>
> While doing so switch an adjacent x86 struct page_info field to bool.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 29/08/2024 12:59 pm, Jan Beulich wrote:
> ... and move the type itself to linux-compat.h.
>
> While doing so,
> - convert __read_mostly to __ro_after_init for respective variables
> having their type changed (for acpi_numa add the attribute anew),
> - in cpuid_hypervisor_leaves() drop a cast a
Hi Jan,
On 29/08/2024 08:54, Jan Beulich wrote:
On 22.08.2024 12:52, Ayan Kumar Halder wrote:
I will update the commit message as below. Let me know if this makes
sense.
Certainly better. One more question though:
```
xen: make VMAP support in MMU system only
Introduce CONFIG_HAS_VMAP wh
On 29.08.2024 14:04, oleksii.kuroc...@gmail.com wrote:
> On Thu, 2024-08-29 at 09:01 +0200, Jan Beulich wrote:
>> On 28.08.2024 18:11, oleksii.kuroc...@gmail.com wrote:
>>> On Tue, 2024-08-27 at 17:00 +0200, Jan Beulich wrote:
On 21.08.2024 18:06, Oleksii Kurochko wrote:
> @@ -68,6 +111,20
Hi Ayan,
> On 29 Aug 2024, at 13:31, Ayan Kumar Halder wrote:
>
> From: Michal Orzel
>
> Add the requirements for the use of generic timer by a domain
>
> Signed-off-by: Michal Orzel
> Signed-off-by: Ayan Kumar Halder
> Reviewed-by: Stefano Stabellini
Reviewed-by: Bertrand Marquis
Chee
On 29/08/2024 12:58 pm, Jan Beulich wrote:
> Use uint_t instead (s were unused altogether). While adjusting
> swap() drop excessive casts and rename the arguments to avoid leading
> underscores.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
... and move the type itself to linux-compat.h.
While doing so
- correct the type of union uu's uq field in lib/divmod.c,
- switch a few adjacent types as well, for (a little bit of)
consistency.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/arm64/cpufeature.c
+++ b/xen/arch/arm/arm64/cpufeat
On 29/08/2024 12:52 pm, Frediano Ziglio wrote:
> diff --git a/xen/arch/x86/boot/defs.h b/xen/arch/x86/boot/defs.h
> index 239b9f8716..ee1a4da6af 100644
> --- a/xen/arch/x86/boot/defs.h
> +++ b/xen/arch/x86/boot/defs.h
> @@ -57,7 +57,7 @@ typedef u16 uint16_t;
> typedef u32 uint32_t;
> typedef u64
On Thu, 2024-08-29 at 09:01 +0200, Jan Beulich wrote:
> On 28.08.2024 18:11, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-08-27 at 17:00 +0200, Jan Beulich wrote:
> > > On 21.08.2024 18:06, Oleksii Kurochko wrote:
> > > > Implement map_pages_to_xen() which requires several
> > > > functions t
On 29/08/2024 12:47 pm, Jan Beulich wrote:
> Prior work has fully eliminated that hardcoded boundary.
I'd cite e.g. commit cbabbc9f5659 ("x86/boot: Size the boot/directmap
mappings dynamically") here.
> Drop both the
> linker script assertion (the upper bound is now the stubs area) and the
> art
... and move the type itself to linux-compat.h.
While doing so switch a few adjacent types as well, for (a little bit
of) consistency.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -63,7 +63,7 @@ static u32 get_alt_insn(const struct alt
i
... and move the type itself to linux-compat.h.
While doing so switch an adjacent x86 struct page_info field to bool.
Signed-off-by: Jan Beulich
--- a/xen/arch/arm/arm32/livepatch.c
+++ b/xen/arch/arm/arm32/livepatch.c
@@ -135,7 +135,7 @@ static s32 get_addend(unsigned char type
addend
... and move the type itself to linux-compat.h.
While doing so,
- convert __read_mostly to __ro_after_init for respective variables
having their type changed (for acpi_numa add the attribute anew),
- in cpuid_hypervisor_leaves() drop a cast altogether,
- switch an adjacent struct arch_irq_desc f
Use uint_t instead (s were unused altogether). While adjusting
swap() drop excessive casts and rename the arguments to avoid leading
underscores.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -17,14 +17,6 @@
#include
#include
-#define u8
Replace uses except where linux-compat.h, where they're moved to, is
sensible to #include.
1: x86: drop s/u overrides from mkelf32
2: types: replace remaining uses of s8
3: types: replace remaining uses of s16
4: types: replace remaining uses of s32
5: types: replace remaining uses of s64
Jan
Just style update, no functional change.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/cmdline.c | 30 ++---
xen/arch/x86/boot/defs.h| 2 +-
xen/arch/x86/boot/reloc.c | 38 ++---
3 files changed, 35 insertions(+), 35 deletions
Prior work has fully eliminated that hardcoded boundary. Drop both the
linker script assertion (the upper bound is now the stubs area) and the
artificial extending of xen.efi's image size.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -359,14 +359,6 @@ S
From: Michal Orzel
Add the requirements for the use of generic timer by a domain
Signed-off-by: Michal Orzel
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Stefano Stabellini
---
Changes from -
v1 - 1. Fixed some wordings as suggested in v1.
2. Removed the comments which mentions Domain speci
Hi all,
I'd like to thank Oleksii for his hard work as the release manager for 4.19.
As we prepare for our next release, we welcome any interest from the
community in becoming the next release manager.
Feel free to reply directly with your interest, or you can raise this in
the community call.
Hello,
To give some context, this started as a bug report against FreeBSD failing to
work with PV blkif attached disks with 4K logical sectors when the backend is
Linux kernel blkback:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280884
Further investigation has lead me to discover that the
Thanks both.
I'll look to see what's possible, although if anyone could help automate
this monthly that would be greatly helpful!
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Mon, Aug 19, 2024 at 9:38 AM Jan Beulich wrote:
> On 16.08.2024 20:25, Stefano Stabellini wrote:
> > xen.b
On 29/08/2024 10:05 am, Sergiy Kibrik wrote:
> Platform Shared Resource feature is available for certain Intel's CPUs only,
> hence can be put under CONFIG_INTEL build option.
AMD implement PSR too, and even some extensions over what Intel implement.
Furthermore it is likely that the eventual aut
On 29.08.2024 11:48, Sergiy Kibrik wrote:
> 19.08.24 15:36, Jan Beulich:
>> On 16.08.2024 13:19, Sergiy Kibrik wrote:
>>> --- a/xen/arch/x86/hvm/svm/svm.c
>>> +++ b/xen/arch/x86/hvm/svm/svm.c
>>> @@ -919,7 +919,8 @@ static void cf_check svm_ctxt_switch_from(struct vcpu
>>> *v)
>>>* Possibl
flight 187388 linux-linus real [real]
flight 187399 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187388/
http://logs.test-lab.xenproject.org/osstest/logs/187399/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
19.08.24 15:36, Jan Beulich:
On 16.08.2024 13:19, Sergiy Kibrik wrote:
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -919,7 +919,8 @@ static void cf_check svm_ctxt_switch_from(struct vcpu *v)
* Possibly clear previous guest selection of SSBD if set. Note that
flight 187398 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187398/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 31f022500549f1d862af531da704a9b3c6568ff5
baseline version:
ovmf 2fe9b6c22fcc9b8617b95
19.08.24 11:53, Jan Beulich:
On 16.08.2024 13:10, Sergiy Kibrik wrote:
--- a/xen/arch/x86/Kconfig.cpu
+++ b/xen/arch/x86/Kconfig.cpu
@@ -10,6 +10,25 @@ config AMD
May be turned off in builds targetting other vendors. Otherwise,
must be enabled for Xen to work suitably on AMD
Platform Shared Resource feature is available for certain Intel's CPUs only,
hence can be put under CONFIG_INTEL build option.
When !INTEL then PSR-related sysctls XEN_SYSCTL_psr_cmt_op &
XEN_SYSCTL_psr_alloc are off as well.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
v2 patch here:
https
On Mon, Aug 19, 2024 at 3:30 PM Frediano Ziglio
wrote:
>
> Although code is compiled with -fpic option data is not position
> independent. This causes data pointer to become invalid if
> code is not relocated properly which is what happens for
> efi_multiboot2 which is called by multiboot entry co
On Wed, 2024-08-28 at 11:42 +0200, Jan Beulich wrote:
> On 28.08.2024 11:21, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-08-27 at 12:06 +0200, Jan Beulich wrote:
> > > On 21.08.2024 18:06, Oleksii Kurochko wrote:
> > > > In Xen, memory-ordered atomic operations are not necessary,
> > >
> >
On 22.08.2024 12:52, Ayan Kumar Halder wrote:
> I will update the commit message as below. Let me know if this makes
> sense.
Certainly better. One more question though:
> ```
> xen: make VMAP support in MMU system only
>
> Introduce CONFIG_HAS_VMAP which is selected by the architectures that
On 29.08.2024 09:28, Michal Orzel wrote:
> On 29/08/2024 07:55, Jan Beulich wrote:
>> With the original code I observe
>>
>> In function ‘__irq_to_desc’,
>> inlined from ‘route_irq_to_guest’ at arch/arm/irq.c:465:12:
>> arch/arm/irq.c:54:16: error: array subscript -2 is below array bounds of
>
On Wed, Aug 28, 2024 at 07:57:39PM +0100, Andrew Cooper wrote:
> On 28/08/2024 2:02 pm, Roger Pau Monné wrote:
> > On Wed, Aug 28, 2024 at 12:51:23PM +0100, Andrew Cooper wrote:
> >> On 28/08/2024 12:50 pm, Jan Beulich wrote:
> >>> On 28.08.2024 13:30, Roger Pau Monne wrote:
> Move the logic t
On 29/08/2024 07:55, Jan Beulich wrote:
>
>
> With the original code I observe
>
> In function ‘__irq_to_desc’,
> inlined from ‘route_irq_to_guest’ at arch/arm/irq.c:465:12:
> arch/arm/irq.c:54:16: error: array subscript -2 is below array bounds of
> ‘irq_desc_t[32]’ {aka ‘struct irq_des
On 29.08.2024 02:35, Stefano Stabellini wrote:
> On Mon, 29 Jul 2024, Stefano Stabellini wrote:
>> On Mon, 29 Jul 2024, Federico Serafini wrote:
>>> Add defensive return statement at the end of an unreachable
>>> default case. Other than improve safety, this meets the requirements
>>> to deviate a
On 28.08.2024 18:11, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-27 at 17:00 +0200, Jan Beulich wrote:
>> On 21.08.2024 18:06, Oleksii Kurochko wrote:
>>> Implement map_pages_to_xen() which requires several
>>> functions to manage page tables and entries:
>>> - pt_update()
>>> - pt_mapping_
76 matches
Mail list logo
