On 22/06/24 14:22, Andrew Cooper wrote:
On 22/06/2024 11:48 am, Federico Serafini wrote:
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index e2653f77eb..6bdfe7c883 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
++
On 21.06.2024 13:40, Petr Beneš wrote:
> On Thu, Jun 20, 2024 at 9:25 AM Jan Beulich wrote:
>> Not exactly. You may not assert on idx. The assertion, if any, wants to
>> check d->nr_altp2m against MAX_EPTP.
>
> In addition to the check in arch_sanitize_domain? As a safeguard?
Well. Such an asser
On 22.06.2024 01:27, Stefano Stabellini wrote:
> On Fri, 21 Jun 2024, Jan Beulich wrote:
>> On 21.06.2024 03:02, Stefano Stabellini wrote:
>>> On Thu, 20 Jun 2024, Jan Beulich wrote:
On 19.06.2024 19:09, Alessandro Zucchelli wrote:
> Rule 21.2 reports identifiers reserved for the C and POS
On 21.06.2024 18:55, Anthony PERARD wrote:
> On Fri, Jun 21, 2024 at 05:16:56PM +0100, Andrew Cooper wrote:
>> `xl devd` has been observed leaking /var/log/xldevd.log into children.
>>
>> Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on newfd, so
>> after setting up stdout/stderr
On 21.06.2024 18:59, Andrew Cooper wrote:
> On 21/06/2024 5:55 pm, Anthony PERARD wrote:
>> On Fri, Jun 21, 2024 at 05:16:56PM +0100, Andrew Cooper wrote:
>>> `xl devd` has been observed leaking /var/log/xldevd.log into children.
>>>
>>> Note this is specifically safe; dup2() leaves O_CLOEXEC disab
flight 186464 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186464/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 186462
Tests which did not
On Fri, 2024-06-21 at 15:24 -0700, Stefano Stabellini wrote:
> On Wed, 19 Jun 2024, Stefano Stabellini wrote:
> > On Fri, 14 Jun 2024, Federico Serafini wrote:
> > > Update ECLAIR configuration to deviate some cases where not using
> > > the return value of a function is not dangerous.
> > >
> > >
On Fri, 2024-06-21 at 15:07 -0700, Stefano Stabellini wrote:
> On Thu, 20 Jun 2024, Stefano Stabellini wrote:
> > On Thu, 20 Jun 2024, Federico Serafini wrote:
> > > MISRA C Rule 5.5 states that "Identifiers shall be distinct from
> > > macro
> > > names".
> > >
> > > Update ECLAIR configuration t
Reflect the latest Xen support to be able to omit the host physical
address for static shared memory regions, in which case the address will
come from the Xen heap.
Signed-off-by: Michal Orzel
---
README.md| 7 ---
scripts/uboot-script-gen | 19 +--
2 files c
On 21.06.2024 22:58, Andrew Cooper wrote:
> Right now, the non-compat declaration and definition of do_multicall()
> differing types for the nr_calls parameter.
>
> This is a MISRA rule 8.3 violation, but it's also time-bomb waiting for the
> first 128bit architecture (RISC-V looks as if it might
On Fri, 2024-06-21 at 21:57 +0100, Andrew Cooper wrote:
> This gets Xen clean to R8.3 and marks it as blocking in Gitlab.
>
> https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1342755199
>
> Andrew Cooper (2):
> x86/pagewalk: Address MISRA R8.3 violation in guest_walk_tables()
> x
On Fri, 2024-06-21 at 14:33 -0700, Stefano Stabellini wrote:
> On Fri, 21 Jun 2024, Federico Serafini wrote:
> > Add more accepted guidelines to the monitored set to check them at
> > each
> > commit.
> >
> > Signed-off-by: Federico Serafini
>
> Acked-by: Stefano Stabellini
>
> Asking for a re
On Fri, 2024-06-21 at 14:31 -0700, Stefano Stabellini wrote:
> On Fri, 21 Jun 2024, Alessandro Zucchelli wrote:
> > This addresses violations of MISRA C:2012 Rule 7.3 which states as
> > following: the lowercase character `l' shall not be used in a
> > literal
> > suffix.
> >
> > The file common/u
On Fri, 2024-06-21 at 21:19 +0100, Andrew Cooper wrote:
> In aid of getting the RISC-V build working without introducing more
> technical
> debt. It's done by making PPC shed it's copy of said technical debt.
>
> Build tested quite thoroughly, including in Gitlab.
Release-Acked-by: Oleksii Kuroch
On 21.06.2024 22:19, Andrew Cooper wrote:
> RISC-V wants to introduce a full build of Xen without using the legacy
> definitions. PPC64 has the most minimal full build of Xen right now, so make
> it compile without the legacy definitions.
>
> Mostly this is just including xen/sections.h in a vari
On Fri, 2024-06-21 at 21:19 +0100, Andrew Cooper wrote:
> Hide the legacy __ro_after_init definition in xen/cache.h for RISC-V,
> to avoid
> its use creeping in. Only mm.c needs adjusting as a consequence
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Shawn Anastasio
>
On Fri, 2024-06-21 at 21:19 +0100, Andrew Cooper wrote:
> RISC-V wants to introduce a full build of Xen without using the
> legacy
> definitions. PPC64 has the most minimal full build of Xen right now,
> so make
> it compile without the legacy definitions.
>
> Mostly this is just including xen/se
On 24.06.2024 10:02, Oleksii wrote:
> On Fri, 2024-06-21 at 21:19 +0100, Andrew Cooper wrote:
>> Hide the legacy __ro_after_init definition in xen/cache.h for RISC-V,
>> to avoid
>> its use creeping in. Only mm.c needs adjusting as a consequence
>>
>> No functional change.
>>
>> Signed-off-by: And
On Fri, 2024-06-21 at 17:34 +0100, Andrew Cooper wrote:
> On 15/04/2024 4:41 pm, Andrew Cooper wrote:
> > This started off as patch 3, and grew somewhat.
> >
> > Patches 1-3 are simple and hopefully non-controversial.
> >
> > Patch 4 is an attempt to make the headers less fragile, but came
> > wi
On Fri, 2024-06-21 at 19:06 +0100, Andrew Cooper wrote:
> Patches 1-3 were my review feedback to Jan's patch 4.
>
> For 4.19. Patch 4 (the bugfix) was Release-Acked after I posted the
> series
> (cleanup and rebased bugfix), which suggests your happy for it in
> principle,
> but I can't treat tha
On 21.06.2024 10:15, Chen, Jiqian wrote:
> On 2024/6/20 18:37, Jan Beulich wrote:
>> On 20.06.2024 12:23, Chen, Jiqian wrote:
>>> On 2024/6/20 15:43, Jan Beulich wrote:
On 20.06.2024 09:03, Chen, Jiqian wrote:
> On 2024/6/18 17:13, Jan Beulich wrote:
>> On 18.06.2024 10:10, Chen, Jiqia
On Fri, 2024-06-21 at 17:16 +0100, Andrew Cooper wrote:
> `xl devd` has been observed leaking /var/log/xldevd.log into
> children.
>
> Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on
> newfd, so
> after setting up stdout/stderr, it's only the logfile fd which will
> close on
>
On 21.06.2024 10:20, Chen, Jiqian wrote:
> On 2024/6/20 18:42, Jan Beulich wrote:
>> On 20.06.2024 11:40, Chen, Jiqian wrote:
>>> On 2024/6/18 17:23, Jan Beulich wrote:
On 18.06.2024 10:23, Chen, Jiqian wrote:
> On 2024/6/17 23:32, Jan Beulich wrote:
>> On 17.06.2024 11:00, Jiqian Chen
ble at:
https://download.01.org/0day-ci/archive/20240624/202406241546.6bbd44a7-oliver.s...@intel.com
=
compiler/cpufreq_governor/disk/filesize/fs2/fs/iterations/kconfig/nr_directories/nr_files_per_directory/nr_t
This is odd to say at least. Any chance you can check the value
of /sys/block/$DEVICE/queue/rotational for the relevant device before
and after this commit? And is this an ATA or NVMe SSD?
Rule 21.2 reports identifiers reserved for the C and POSIX standard
libraries: or, and, not and xor are reserved identifiers because they
constitute alternate spellings for the corresponding operators (they are
defined as macros by iso646.h); however Xen doesn't use standard library
headers, so the
On 21.06.2024 20:06, Andrew Cooper wrote:
> trace_shadow_fixup() and trace_not_shadow_fault() both write out identical
> trace records. Reimplement them in terms of a common sh_trace_gl1e_va().
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 21.06.2024 20:06, Andrew Cooper wrote:
> sh_trace_gfn_va() is very similar to sh_trace_gl1e_va(), and a rather shorter
> name than trace_shadow_emulate_other().
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 21.06.2024 11:50, Nicola Vetrini wrote:
> From: Alessandro Zucchelli
>
> This addresses violations of MISRA C:2012 Rule 5.3 which states as
> following: An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope. In this case the shadowing is between
> l
Escape the final dot of the comment and extend the search of a
fallthrough comment up to 2 lines after the last statement.
Fixes: a128d8da913b21eff6c6d2e2a7d4c54c054b78db "automation/eclair: add
deviations for MISRA C:2012 Rule 16.3"
Reported-by: Jan Beulich
Signed-off-by: Federico Serafini
---
Add missing break statements to address violations of MISRA C Rule
16.3: "An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/cpu/vpmu.c | 3 +++
xen/arch/x86/cpu/vpmu_intel.c | 1 +
2 files chang
This patch series fixes a missing escape in a deviation and addresses some
violations.
Federico Serafini (13):
automation/eclair: fix deviation of MISRA C Rule 16.3
x86/cpuid: use fallthrough pseudo keyword
x86/domctl: address a violation of MISRA C Rule 16.3
x86/vpmu: address violations o
MISRA C Rule 16.3 states that "An unconditional `break' statement shall
terminate every switch-clause".
Add pseudo keyword fallthrough or missing break statement
to address violations of the rule.
As a defensive measure, return -EOPNOTSUPP in case an unreachable
return statement is reached.
Sign
Add pseudo keyword fallthrough to meet the requirements to deviate
a violation of MISRA C Rule 16.3 ("An unconditional `break'
statement shall terminate every switch-clause").
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/hvm/vpt.c | 2 ++
1 file changed, 2 insertions(
Add pseudokeyword fallthrough to meet the requirements to deviate
a violation of MISRA C Rul 16.3: "An unconditional `break' statement
shall terminate every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/hvm/vpic.c | 1 +
1 file changed, 1 insertion(+)
Add missing break statements to address violations of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/cpu/mcheck/mce_amd.c | 1 +
xen/arch/x86/cpu/mcheck/mce_intel.c | 2 ++
2
Add a missing break statement to address a violation of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/mpparse.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86
Add break or pseudo keyword fallthrough to address violations of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/xe
Add missing break statement to address a violation of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/domctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/do
The current comment making explicit the fallthrough intention does
not follow the agreed syntax: replace it with the pseduo keyword.
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/cpuid.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/arch/x86
Add defensive return statement at the end of an unreachable
default case. Other than improve safety, this meets the requirements
to deviate a violation of MISRA C Rule 16.3: "An unconditional `break'
statement shall terminate every switch-clause".
Signed-off-by: Federico Serafini
---
xen/arch/x8
Add missing break statement to address a violation of MISRA C
Rule 16.3: "An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/hvm/vlapic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x8
Add missing break statement to address a violation of MISRA C Rule 16.3
("An unconditional `break' statement shall terminate every
switch-clause").
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/hvm/pmtimer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/
Rule 13.6 states that "The operand of the `sizeof' operator shall not
contain any expression which has potential side effects".
Define service B.UNEVALEFF as an extension of Rule 13.6 to
check for unevalued side effects also for typeof and alignof operators.
Update ECLAIR configuration to deviate
Signed-off-by: George Dunlap
---
CC: Oleksii Kurochko
CC: Community Manager
CC: Andrew Cooper
---
CHANGELOG.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f3c6c7954f..35c3488f4b 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -21,6 +21,8 @@ The form
Signed-off-by: George Dunlap
---
CC: Oleksii Kurochko
CC: Community Manager
---
CHANGELOG.md | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 1778419cae..f3c6c7954f 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -31,12 +31,12 @@
Signed-off-by: Anthony PERARD
---
MAINTAINERS | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e2b30a345..9d66b898ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -208,7 +208,7 @@ Maintainers List (try to look for most precise areas f
On 24/06/2024 10:04 am, George Dunlap wrote:
> Signed-off-by: George Dunlap
Acked-by: Andrew Cooper
On 24/06/2024 10:04 am, George Dunlap wrote:
> Signed-off-by: George Dunlap
Acked-by: Andrew Cooper
On 21/06/2024 5:55 pm, Anthony PERARD wrote:
> On Fri, Jun 21, 2024 at 05:16:56PM +0100, Andrew Cooper wrote:
>> `xl devd` has been observed leaking /var/log/xldevd.log into children.
>>
>> Note this is specifically safe; dup2() leaves O_CLOEXEC disabled on newfd, so
>> after setting up stdout/stde
Hi Michal,
On 21/06/2024 10:22, Michal Orzel wrote:
As a follow up to commit cb1ddafdc573 ("xen/arm/static-shmem: Static-shmem
should be direct-mapped for direct-mapped domains") add a check to
request that both host and guest physical address must be supplied for
direct mapped domains. Otherwis
Hi Julien,
On 24/06/2024 12:22, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 21/06/2024 10:22, Michal Orzel wrote:
>> As a follow up to commit cb1ddafdc573 ("xen/arm/static-shmem: Static-shmem
>> should be direct-mapped for direct-mapped domains") add a check to
>> request that both host and gue
On 24.06.2024 11:04, Federico Serafini wrote:
> Escape the final dot of the comment and extend the search of a
> fallthrough comment up to 2 lines after the last statement.
>
> Fixes: a128d8da913b21eff6c6d2e2a7d4c54c054b78db "automation/eclair: add
> deviations for MISRA C:2012 Rule 16.3"
Nit: Y
xenalyze sets argp_program_bug_address to my old Citrix address. This
was done before xenalyze was in the xen.git tree; and it's the only
program in the tree which does so.
Now that xenalyze is part of the normal Xen distribution, it should be
obvious where to report bugs.
Signed-off-by: George
On 2024-06-23 4:21 am, Baolu Lu wrote:
On 6/21/24 11:09 PM, Teddy Astie wrote:
Le 19/06/2024 à 18:30, Jason Gunthorpe a écrit :
On Thu, Jun 13, 2024 at 01:50:22PM +, Teddy Astie wrote:
+struct iommu_domain *xen_iommu_domain_alloc(unsigned type)
+{
+ struct xen_iommu_domain *domain;
+
On 24/06/2024 11:49 am, George Dunlap wrote:
> xenalyze sets argp_program_bug_address to my old Citrix address. This
> was done before xenalyze was in the xen.git tree; and it's the only
> program in the tree which does so.
>
> Now that xenalyze is part of the normal Xen distribution, it should be
flight 186465 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186465/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186458
test-amd64-amd64-xl-qemut-win7-amd64
On Fri, Jun 21, 2024 at 08:34:11AM +, Chen, Jiqian wrote:
> On 2024/6/20 22:38, Anthony PERARD wrote:
> > On Mon, Jun 17, 2024 at 05:00:34PM +0800, Jiqian Chen wrote:
> >> diff --git a/tools/include/xencall.h b/tools/include/xencall.h
> >> index fc95ed0fe58e..750aab070323 100644
> >> --- a/tool
When re-working them to avoid UB on guest address calculations, I failed
to add explicit type checks in exchange for the implicit ones that until
then had happened in assignments that were there anyway.
Fixes: 43d5c5d5f70b ("xen: avoid UB in guest handle arithmetic")
Signed-off-by: Jan Beulich
-
Much like noted in 43d5c5d5f70b ("xen: avoid UB in guest handle
arithmetic"), address calculations involved in accessing a struct field
can overflow, too. Cast respective pointers to "unsigned long" and
convert type checking accordingly. Remaining arithmetic is, despite
there possibly being mathema
On Fri, Jun 21, 2024 at 08:20:55AM +, Chen, Jiqian wrote:
> On 2024/6/20 18:42, Jan Beulich wrote:
> > On 20.06.2024 11:40, Chen, Jiqian wrote:
> >> On 2024/6/18 17:23, Jan Beulich wrote:
> >>> On 18.06.2024 10:23, Chen, Jiqian wrote:
> On 2024/6/17 23:32, Jan Beulich wrote:
> > On 17.
Hi all,
I recently found this mailing list thread when searching for information on a
related issue regarding conflicting E820 on a Threadripper platform. For those
interested in additional data points, I am using the ASUS WRX80E-SAGE SE Wifi
II motherboard that presents the following E820 to X
On Fri, 2024-06-21 at 21:19 +0100, Andrew Cooper wrote:
> Hide the legacy __ro_after_init definition in xen/cache.h for RISC-V,
> to avoid
> its use creeping in. Only mm.c needs adjusting as a consequence
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Oleksii Kurochko
On Mon, 2024-06-24 at 10:04 +0200, Jan Beulich wrote:
> On 24.06.2024 10:02, Oleksii wrote:
> > On Fri, 2024-06-21 at 21:19 +0100, Andrew Cooper wrote:
> > > Hide the legacy __ro_after_init definition in xen/cache.h for
> > > RISC-V,
> > > to avoid
> > > its use creeping in. Only mm.c needs adjust
On Mon, 2024-06-24 at 10:04 +0100, George Dunlap wrote:
> Signed-off-by: George Dunlap
> ---
> CC: Oleksii Kurochko
> CC: Community Manager
Release-Acked-by: Oleksii Kurochko
~ Oleksii
> ---
> CHANGELOG.md | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git
On Mon, 2024-06-24 at 11:49 +0100, George Dunlap wrote:
> xenalyze sets argp_program_bug_address to my old Citrix address.
> This
> was done before xenalyze was in the xen.git tree; and it's the only
> program in the tree which does so.
>
> Now that xenalyze is part of the normal Xen distribution
On 24.06.2024 14:40, Branden Sherrell wrote:
> I recently found this mailing list thread when searching for information on a
> related issue regarding conflicting E820 on a Threadripper platform. For
> those interested in additional data points, I am using the ASUS WRX80E-SAGE
> SE Wifi II mothe
What is the reasoning that this fix be applied only to PVH domains? Taking a
look at the fix logic it appears to walk the E820 to find a suitable range of
memory to load the kernel into (assuming it can be determined that the kernel
is also relocatable). Why can this logic not be applied to dom0
On 24/06/2024 1:26 pm, Jan Beulich wrote:
> When re-working them to avoid UB on guest address calculations, I failed
> to add explicit type checks in exchange for the implicit ones that until
> then had happened in assignments that were there anyway.
>
> Fixes: 43d5c5d5f70b ("xen: avoid UB in guest
From: Charles Arnold
gcc14 no longer (silently) accepts functions with no return type
specified.
Signed-off-by: Charles Arnold
Signed-off-by: Jan Beulich
--- a/include/posix/sys/mman.h
+++ b/include/posix/sys/mman.h
@@ -16,7 +16,7 @@
void *mmap(void *start, size_t length, int prot, int fla
Jan Beulich, le lun. 24 juin 2024 15:34:53 +0200, a ecrit:
> From: Charles Arnold
>
> gcc14 no longer (silently) accepts functions with no return type
> specified.
>
> Signed-off-by: Charles Arnold
> Signed-off-by: Jan Beulich
Reviewed-by: Samuel Thibault
Thanks!
>
> --- a/include/posix/s
On 24.06.2024 15:07, Branden Sherrell wrote:
> What is the reasoning that this fix be applied only to PVH domains? Taking a
> look at the fix logic it appears to walk the E820 to find a suitable range of
> memory to load the kernel into (assuming it can be determined that the kernel
> is also re
A SSD:
https://download.01.org/0day-ci/archive/20240624/202406241546.6bbd44a7-oliver.s...@intel.com/job.yaml
ssd_partitions:
"/dev/disk/by-id/ata-INTEL_SSDSC2BG012T4_BTHC428201ZX1P2OGN-part1"
Most likely btrfs does something different depending on the nonrot flag
being set or not. (And l
Hi,
Some Qubes users report a regression in xen-blkfront regarding block
size reporting. It works fine on 6.8.8, but appears broken on 6.9.2.
The specific problem is that blkfront reports block size of 512, even for
backend devices of 4096. This, for example, fails 512-bytes reads with
O_DIRECT,
On 17.06.24 16:25, Jan Beulich wrote:
On 17.06.2024 16:03, Marek Marczykowski-Górecki wrote:
On Mon, Jun 17, 2024 at 01:22:37PM +0200, Jan Beulich wrote:
Hello,
while it feels like we had a similar situation before, I can't seem to be
able to find traces thereof, or associated (Linux) commits.
On 18/04/2024 10:00 am, Jan Beulich wrote:
> On 15.04.2024 17:41, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
> While I don't mind the change as is, "sort" is ambiguous here in one regard.
> Personally I'd prefer if those parts of the change were dropped, but I can
> live with the sorting
Hi Stefano,
On 22/06/24 02:14, Stefano Stabellini wrote:
From: Stefano Stabellini
This patch adds a bunch of rules to rules.rst that are uncontroversial
and have zero violations in Xen. As such, they have been approved for
adoption.
All the ones that regard the standard library have the link
S3610 I think. Be sure to use sst or the chassis vendor’s tool to update the
firmware.
> On Jun 24, 2024, at 9:45 AM, Niklas Cassel wrote:
>
> SSDSC2BG012T4
On 24.06.24 15:48, Marek Marczykowski-Górecki wrote:
Hi,
Some Qubes users report a regression in xen-blkfront regarding block
size reporting. It works fine on 6.8.8, but appears broken on 6.9.2.
The specific problem is that blkfront reports block size of 512, even for
backend devices of 4096. T
Hello Robin,
Thanks for the thourough review.
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index 0af39bbbe3a3..242cefac77c9 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -480,6 +480,15 @@ config VIRTIO_IOMMU
>> Say Y here if you intend to ru
On Mon, Jun 24, 2024 at 04:29:15PM +0200, Jürgen Groß wrote:
>> Rusty suspects it's related to
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/block/xen-blkfront.c?id=ba3f67c1163812b5d7ec33705c31edaa30ce6c51,
>> so I'm cc-ing people mentioned there too.
>
> I th
On 24.06.2024 11:04, Federico Serafini wrote:
> The current comment making explicit the fallthrough intention does
> not follow the agreed syntax: replace it with the pseduo keyword.
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 24.06.2024 11:04, Federico Serafini wrote:
> Add missing break statement to address a violation of
> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
> every switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 24.06.2024 11:04, Federico Serafini wrote:
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
> @@ -713,6 +713,7 @@ static int cf_check core2_vpmu_do_rdmsr(unsigned int msr,
> uint64_t *msr_content)
> break;
> default:
> rdmsrl(msr, *m
On 24.06.2024 11:04, Federico Serafini wrote:
> Add break or pseudo keyword fallthrough to address violations of
> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
> every switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Technically the change
On Mon, Jun 24, 2024 at 03:45:57PM +0200, Niklas Cassel wrote:
> Seems to be ATA SSD:
> https://download.01.org/0day-ci/archive/20240624/202406241546.6bbd44a7-oliver.s...@intel.com/job.yaml
>
> ssd_partitions:
> "/dev/disk/by-id/ata-INTEL_SSDSC2BG012T4_BTHC428201ZX1P2OGN-par
On 24.06.2024 11:04, Federico Serafini wrote:
> Add missing break statements to address violations of
> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
> every switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 24.06.2024 11:04, Federico Serafini wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -339,7 +339,7 @@ static int hvmemul_do_io(
> }
> case X86EMUL_UNIMPLEMENTED:
> ASSERT_UNREACHABLE();
> -/* Fall-through */
> +fallthrough;
>
On 24.06.2024 11:04, Federico Serafini wrote:
> --- a/xen/arch/x86/hvm/vpt.c
> +++ b/xen/arch/x86/hvm/vpt.c
> @@ -121,6 +121,8 @@ static int pt_irq_masked(struct periodic_time *pt)
> }
>
> /* Fallthrough to check if the interrupt is masked on the IO APIC. */
> +fallthrough;
> +
>
On 24.06.2024 11:04, Federico Serafini wrote:
> Add defensive return statement at the end of an unreachable
> default case. Other than improve safety,
It is particularly with this in mind that ...
> this meets the requirements
> to deviate a violation of MISRA C Rule 16.3: "An unconditional `brea
On 24.06.2024 11:04, Federico Serafini wrote:
> Add a missing break statement to address a violation of
> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
> every switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 24.06.2024 11:04, Federico Serafini wrote:
> Add missing break statement to address a violation of MISRA C Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause").
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
I'm curi
On 24.06.2024 11:04, Federico Serafini wrote:
> Add pseudokeyword fallthrough to meet the requirements to deviate
> a violation of MISRA C Rul 16.3: "An unconditional `break' statement
> shall terminate every switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-b
On 24.06.2024 11:04, Federico Serafini wrote:
> Add missing break statement to address a violation of MISRA C
> Rule 16.3: "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
Acked-by: Jan Beulich
On 21.06.2024 21:14, Tamas K Lengyel wrote:
> @@ -58,6 +58,9 @@ afl-harness: afl-harness.o $(OBJS) cpuid.o wrappers.o
> afl-harness-cov: afl-harness-cov.o $(patsubst %.o,%-cov.o,$(OBJS)) cpuid.o
> wrappers.o
> $(CC) $(CFLAGS) $(GCOV_FLAGS) $(addprefix
> -Wl$(comma)--wrap=,$(WRAPPED)) $^ -o
Sorry about that. The thread quickly diverged from the core issue to helping
diagnose GPU issues, so I thought it best to circle back to the ticket
reference to realign.
In any event, if there is any aid I can provide on this front please let me
know. I have worked around this issue for now by
On Mon, 24 Jun 2024, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
On Mon, Jun 24, 2024 at 02:36:45PM +, Teddy Astie wrote:
> >> +bool xen_iommu_capable(struct device *dev, enum iommu_cap cap)
> >> +{
> >> + switch (cap) {
> >> + case IOMMU_CAP_CACHE_COHERENCY:
> >> + return true;
> >
> > Will the PV-IOMMU only ever be exposed on hardware where th
On 24/06/2024 11:43, Michal Orzel wrote:
Hi Julien,
On 24/06/2024 12:22, Julien Grall wrote:
Hi Michal,
On 21/06/2024 10:22, Michal Orzel wrote:
As a follow up to commit cb1ddafdc573 ("xen/arm/static-shmem: Static-shmem
should be direct-mapped for direct-mapped domains") add a check to
r
On Mon, Jun 17, 2024 at 08:04:41AM +0200, Christoph Hellwig wrote:
> -#define blk_queue_nonrot(q) test_bit(QUEUE_FLAG_NONROT, &(q)->queue_flags)
> +#define blk_queue_nonrot(q) ((q)->limits.features & BLK_FEAT_ROTATIONAL)
This is inverted. Should be:
#define blk_queue_nonrot(q)(!((q)->limit
1 - 100 of 152 matches
Mail list logo
