On 2024-06-21 02:18, Stefano Stabellini wrote:
On Mon, 16 Jun 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".
The helper macro bitmap_switch has parameters that cannot be
parenthesized
in ord
On 24/06/24 12:57, Jan Beulich wrote:
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
flight 186471 xen-unstable real [real]
flight 186478 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186471/
http://logs.test-lab.xenproject.org/osstest/logs/186478/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
Update ECLAIR configuration to deviate more cases where an
unintentional fallthrough cannot happen.
Tag Rule 16.3 as clean for arm.
Signed-off-by: Federico Serafini
Acked-by: Stefano Stabellini
---
Changes from v3:
- do not add the rule to the monitored set (it is already there).
---
Changes fr
On 25.06.2024 02:54, Stefano Stabellini wrote:
> On Mon, 24 Jun 2024, 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.
>>
>> Sig
On 25.06.2024 02:47, Stefano Stabellini wrote:
> I would like to ask for a release-ack as the patch series makes very few
> changes outside of the static analysis configuration. The few changes to
> the Xen code are very limited, straightforward and makes the code
> better, see patch #3 and #5.
Wh
On 25.06.2024 02:15, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Rule 17.7: "The value returned by a function having non-void return type
> shall be used"
>
> This patch fixes this by adding a check to the return value.
> No functional changes.
>
> Signed-off-by: Victor Lira
> ---
> Cc
On 25.06.2024 02:14, Stefano Stabellini wrote:
> I do realize that some of the notifier pattern switches might want to
> handle all parameters but Bugseng or anyone else looking for simple
> improvements are not in the position to tell which ones they are. We
> need to wait for a maintainer or expe
On 24.06.2024 23:40, Julien Grall wrote:
> On 24/06/2024 17:27, Stefano Stabellini wrote:
>> On Mon, 24 Jun 2024, Anthony PERARD wrote:
>>> Signed-off-by: Anthony PERARD
>>
>> Acked-by: Stefano Stabellini
>
> I guess this technically need an ack from the release manager. So CC
> Oleksii.
Hmm,
Christoph Hellwig:
> 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 me
On 24.06.2024 23:23, Tamas K Lengyel wrote:
> On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich wrote:
>>
>> 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)) cp
Ensure that info->sector_size and info->physical_sector_size are set
before the call to blkif_set_queue_limits by doing away with the
local variables and arguments that propagate them.
Thanks to Marek Marczykowski-Górecki and Jürgen Groß for root causing
the issue.
Fixes: ba3f67c11638 ("xen-blkfr
On 25/06/24 02:38, Stefano Stabellini wrote:
On Wed, 19 Jun 2024, Stefano Stabellini wrote:
On Fri, 14 Jun 2024, Federico Serafini wrote:
Update ECLAIR configuration to deviate more cases where an
unintentional fallthrough cannot happen.
Add Rule 16.3 to the monitored set and tag it as clean f
flight 186473 xen-unstable-smoke real [real]
flight 186476 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186473/
http://logs.test-lab.xenproject.org/osstest/logs/186476/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
Hello,
kernel test robot noticed a 22.6% improvement of aim7.jobs-per-min on:
commit: 1122c0c1cc71f740fa4d5f14f239194e06a1d5e7 ("block: move cache control
settings out of queue->flags")
https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git for-next
testcase: aim7
test machine:
flight 186469 linux-linus real [real]
flight 186472 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186469/
http://logs.test-lab.xenproject.org/osstest/logs/186472/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On 6/24/24 7:09 PM, Robin Murphy wrote:
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)
+{
On Mon, 24 Jun 2024, 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
Reviewed-by: Stefano Stabellini
On Mon, 24 Jun 2024, 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
Reviewe
On Mon, 24 Jun 2024, 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
Reviewed-by: Stefano Stabellini
On Mon, 24 Jun 2024, 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
Reviewed-by: Stefano Stabellini
On Mon, 24 Jun 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 violation of MISRA C Rule 16.3: "An unconditional `break'
> statement shall terminate every switch-clause
On Mon, 24 Jun 2024, Federico Serafini wrote:
> 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
Revi
On Mon, 24 Jun 2024, Federico Serafini wrote:
> 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 -EOPNOTSU
On Mon, 24 Jun 2024, 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
Reviewed-by: Stefano Stabellini
On Mon, 24 Jun 2024, 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
> ---
> xen/arch/x86/t
On Mon, 24 Jun 2024, 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
Reviewed-by: Stefano Stabellini
On Mon, 24 Jun 2024, 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
Reviewed-by: Stefano Stabellini
On Mon, 24 Jun 2024, 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
Reviewed-by: Stefano Stabellini
> ---
> xen/a
On Mon, 24 Jun 2024, 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"
> Repor
Hi Oleksii,
I would like to ask for a release-ack as the patch series makes very few
changes outside of the static analysis configuration. The few changes to
the Xen code are very limited, straightforward and makes the code
better, see patch #3 and #5.
On Mon, 17 Jun 2024, Nicola Vetrini wrote:
On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses".
>
> The helper macro bitmap_switch has parameters that cannot be parenthesized
> in order to comply with the rule, as that would
On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses".
>
> The local helpers GRP2 and XADD in the x86 emulator use their first
> argument as the constant expression for a case label.
On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> Remove from the ECLAIR integration scripts an unused option, which
> was already ignored, and make the help texts consistent
> with the rest of the scripts.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
On Wed, 19 Jun 2024, Stefano Stabellini wrote:
> On Fri, 14 Jun 2024, Federico Serafini wrote:
> > Update ECLAIR configuration to deviate more cases where an
> > unintentional fallthrough cannot happen.
> >
> > Add Rule 16.3 to the monitored set and tag it as clean for arm.
> >
> > Signed-off-by:
On Mon, 24 Jun 2024, Stefano Stabellini wrote:
> On Mon, 24 Jun 2024, Federico Serafini wrote:
> > 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
On Mon, 24 Jun 2024, Alessandro Zucchelli wrote:
> 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);
From: Victor Lira
Rule 17.7: "The value returned by a function having non-void return type
shall be used"
This patch fixes this by adding a check to the return value.
No functional changes.
Signed-off-by: Victor Lira
---
Cc: George Dunlap
Cc: Dario Faggioli
Cc: Juergen Gross
Cc: xen-devel@l
On Sat, 22 Jun 2024, Julien Grall wrote:
> On 21/06/2024 23:34, Stefano Stabellini wrote:
> > > > > Yes, I also think this could be an opportunity to check the pattern
> > > > > but no one has yet been identified to do this.
> > > >
> > > > I don't think I understand Julien's question and/or your
On Mon, 24 Jun 2024, Federico Serafini wrote:
> 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 al
flight 186470 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186470/
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 Mon, Jun 24, 2024 at 5:58 PM Julien Grall wrote:
>
> Hi,
>
> On 21/06/2024 20:14, Tamas K Lengyel wrote:
> > The build integration script for oss-fuzz targets.
>
> Do you have any details how this is meant and/or will be used?
https://google.github.io/oss-fuzz/getting-started/new-project-guide
Hi,
On 21/06/2024 20:14, Tamas K Lengyel wrote:
The build integration script for oss-fuzz targets.
Do you have any details how this is meant and/or will be used?
I also couldn't find a cover letter. For series with more than one
patch, it is recommended to have one as it help threading and c
Hi,
On 24/06/2024 17:27, Stefano Stabellini wrote:
On Mon, 24 Jun 2024, Anthony PERARD wrote:
Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
I guess this technically need an ack from the release manager. So CC
Oleksii.
Cheers,
--
Julien Grall
On Mon, Jun 24, 2024 at 11:55 AM Jan Beulich wrote:
>
> 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)
On 2024-06-24 11:00, Jan Beulich wrote:
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
Hi Jason,
On 6/24/2024 9:32 AM, Jason Gunthorpe wrote:
> 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;
>>>
>>> W
flight 186467 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186467/
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 2024-06-24 6:36 pm, Easwar Hariharan wrote:
Hi Jason,
On 6/24/2024 9:32 AM, Jason Gunthorpe wrote:
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:
+
On Mon, Jun 24, 2024 at 10:36:13AM -0700, Easwar Hariharan wrote:
> Hi Jason,
>
> On 6/24/2024 9:32 AM, Jason Gunthorpe wrote:
> > 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)
flight 186466 linux-linus real [real]
flight 186468 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186466/
http://logs.test-lab.xenproject.org/osstest/logs/186468/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
On Mon, Jun 24, 2024 at 11:08:16AM -0600, Keith Busch wrote:
> 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
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
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 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 Mon, 24 Jun 2024, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Acked-by: Stefano Stabellini
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 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
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:
> 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
I'm curi
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 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:
> --- 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:
> --- 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:
> 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 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 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 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 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:
> 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 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
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 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
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
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
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
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.
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,
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
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
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
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
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
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 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
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 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 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 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
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, 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.
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
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
-
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
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 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
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;
+
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 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
1 - 100 of 152 matches
Mail list logo
