flight 186175 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186175/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186168
A few drivers optimistically try to support discard, write zeroes and
secure erase and disable the features from the I/O completion handler
if the hardware can't support them. This disable can't be done using
the atomic queue limits API because the I/O completion handlers can't
take sleeping
Assign all queue limits through a local queue_limits variable and
queue_limits_commit_update so that we can't race updating them from
multiple places, and free the queue when updating them so that
in-progress I/O submissions don't see half-updated limits.
Also use the chance to clean up variable
Remove all APIs that are unused now that sd and sr have been converted
to the atomic queue limits API.
Signed-off-by: Christoph Hellwig
---
block/blk-settings.c | 190 -
include/linux/blkdev.h | 12 ---
2 files changed, 202 deletions(-)
diff --git
Consolidate setting zone-related queue limits in sd_zbc_read_zones
instead of splitting them between sd_zbc_revalidate_zones and
sd_zbc_read_zones, and move the early_zone_information initialization
in sd_zbc_read_zones above setting up the queue limits.
Signed-off-by: Christoph Hellwig
---
Fall through to the main call to blk_queue_max_discard_sectors given that
max_blocks has been initialized to zero above instead of duplicating the
call.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/scsi/sd.c
Discard and Write Zeroes are different operation and implemented
by different fallocate opcodes for ubd. If one fails the other one
can work and vice versa.
Split the code to disable the operations in ubd_handler to only
disable the operation that actually failed.
Fixes: 50109b5a03b4 ("um: Add
Add helper to disable discard when it is not supported and use it
instead of sd_config_discard in the I/O completion handler. This avoids
touching more fields than required in the I/O completion handler and
prepares for converting sd to use the atomic queue limits API.
Signed-off-by: Christoph
Assign all queue limits through a local queue_limits variable and
queue_limits_commit_update so that we can't race updating them from
multiple places, and free the queue when updating them so that
in-progress I/O submissions don't see half-updated limits.
Signed-off-by: Christoph Hellwig
---
Hi all,
this series converts the SCSI upper level drivers to the atomic queue
limits API.
The first patch is a bug fix for ubd that later patches depend on and
might be worth picking up for 6.10.
The second patch changes the max_sectors calculation to take the optimal
I/O size into account so
Split the logic to pick the right discard mode into a little helper
to prepare for further changes.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/sd.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/scsi/sd.c
The soft max_sectors limit is normally capped by the hardware limits and
an arbitrary upper limit enforced by the kernel, but can be modified by
the user. A few drivers want to increase this limit (nbd, rbd) or
adjust it up or down based on hardware capabilities (sd).
Change blk_validate_limits
Add helper to disable WRITE SAME when it is not supported and use it
instead of sd_config_write_same in the I/O completion handler. This
avoids touching more fields than required in the I/O completion handler
and prepares for converting sd to use the atomic queue limits API.
Signed-off-by:
Don't reset the discard settings to no-op over and over when a user
writes to the provisioning attribute as that is already the default
mode for ZBC devices. In hindsight we should have made writing to
the attribute fail for ZBC devices, but the code has probably been
around for far too long to
ping?
On 10/5/24 12:49, Philippe Mathieu-Daudé wrote:
Respin of Paolo's Xen patches from
https://lore.kernel.org/qemu-devel/20240509170044.190795-1-pbonz...@redhat.com/
rebased on one of my cleanup branches making backend
structures const. Treat xenfb as other backends.
Paolo Bonzini (2):
flight 186174 linux-linus real [real]
flight 186177 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186174/
http://logs.test-lab.xenproject.org/osstest/logs/186177/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi,
On 2024/5/17 19:50, Jan Beulich wrote:
> On 17.05.2024 13:14, Chen, Jiqian wrote:
>> On 2024/5/17 18:51, Jan Beulich wrote:
>>> On 17.05.2024 12:45, Chen, Jiqian wrote:
On 2024/5/16 22:01, Jan Beulich wrote:
> On 16.05.2024 11:52, Jiqian Chen wrote:
>> +if ( gsi >=
flight 186178 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186178/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 55f8bddade205c9cbe3583d5d31d0048cdf26ed4
baseline version:
ovmf
flight 186176 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186176/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0e3189d406684e44608e01c93f7e2d53fa07b40a
baseline version:
ovmf
On 2024-05-28 08:28, Jan Beulich wrote:
On 27.05.2024 16:53, Nicola Vetrini wrote:
Rule 8.4 states: "A compatible declaration shall be visible when
an object or function with external linkage is defined."
These variables are only referenced from asm modules, so they
need to be extern and there
flight 186172 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186172/
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
On Mon, May 27, 2024 at 12:58:16PM +0200, Juergen Gross wrote:
> Hi,
>
> I'd like to dispute CVE-2021-47377: the issue fixed by upstream commit
> 8480ed9c2bbd56fc86524998e5f2e3e22f5038f6 can in no way be triggered by
> an unprivileged user or by a remote attack of the system, as it requires
>
flight 186168 xen-unstable real [real]
flight 186173 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186168/
http://logs.test-lab.xenproject.org/osstest/logs/186173/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 28/05/2024 4:29 pm, Fouad Hilly wrote:
> Pass ucode_force to common micorocde checks and utilize it to allow for
> microcode downgrade
> or reapply the same version of the microcode.
> Update low level Intel and AMD to check for valid signature only. Any version
> checks is done
> at core.c.
On 28/05/2024 4:29 pm, Fouad Hilly wrote:
> Introduce --force option to xen-ucode to force skipping microcode version
> check, which
> allows the user to update x86 microcode even if both versions are the same or
> downgrade.
> xc_microcode_update() refactored to accept flags and utilize
>
On 28/05/2024 4:29 pm, Fouad Hilly wrote:
> Use getopt_long() to handle command line arguments.
> Introduce ext_err for common exit with errors.
> xc_microcode_update() refactored to accept flags and utilize
> xenpf_microcode_update2
Importantly, not. That's deferred until the next patch.
>
On 28/05/2024 4:29 pm, Fouad Hilly wrote:
> Refactor microcode_update() by adding flags field.
> struct xenpf_microcode_update2 added with uint32_t flags field.
> Introduce XENPF_microcode_update2 hypercall with flags field.
>
> Signed-off-by: Fouad Hilly
PF_ in the subject wants expanding to
On 22/05/2024 7:03 am, Jan Beulich wrote:
> On 21.05.2024 19:15, Andrew Cooper wrote:
>> These are all either completely unused, or do nothing useful.
>>
>> Signed-off-by: Andrew Cooper
> Not an objection, i.e. you're fine to commit as is with Stefano's R-b, yet
> still a question:
>
>> @@ -30,11
On Tue, 2024-05-28 at 17:37 +0200, Jan Beulich wrote:
> On 28.05.2024 17:32, Andrew Cooper wrote:
> > This avoids having a function call in a typeof() expression.
> >
> > No functional change.
> >
> > Signed-off-by: Andrew Cooper
>
> Acked-by: Jan Beulich
>
Release-Acked-by: Oleksii Kurochko
On 28.05.2024 17:32, Andrew Cooper wrote:
> This avoids having a function call in a typeof() expression.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
This avoids having a function call in a typeof() expression.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/include/asm/hvm/svm/vmcb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Pass ucode_force to common micorocde checks and utilize it to allow for
microcode downgrade
or reapply the same version of the microcode.
Update low level Intel and AMD to check for valid signature only. Any version
checks is done
at core.c.
While adding ucode_force, opt_ucode_allow_same was
Use getopt_long() to handle command line arguments.
Introduce ext_err for common exit with errors.
xc_microcode_update() refactored to accept flags and utilize
xenpf_microcode_update2
Introducing usage() to handle usage\help messages in a common block.
show_curr_cpu is printed to stdout only.
Refactor and introduce --force option to xen-ucode, which skips microcode
version check when updating x86 CPU micocode. A new hypercall introduced
with flags field to facilitate the new option and allow for future flags
as needed.
This change is required to enable developers to load ucode that is
Refactor microcode_update() by adding flags field.
struct xenpf_microcode_update2 added with uint32_t flags field.
Introduce XENPF_microcode_update2 hypercall with flags field.
Signed-off-by: Fouad Hilly
---
[v4]
1- Commit message and description updated.
2- Changing the order of the patches.
Introduce --force option to xen-ucode to force skipping microcode version
check, which
allows the user to update x86 microcode even if both versions are the same or
downgrade.
xc_microcode_update() refactored to accept flags and utilize
xenpf_microcode_update2.
Signed-off-by: Fouad Hilly
---
flight 186170 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186170/
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
... and move x86's stub_selftest() under this new option.
There is value in having these tests included in release builds too.
It will shortly be used to gate the bitops unit tests on all architectures.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC:
On 27/05/2024 09:20, Roger Pau Monné wrote:
> On Fri, May 24, 2024 at 06:16:01PM +0100, Alejandro Vallejo wrote:
>> On 24/05/2024 09:58, Roger Pau Monné wrote:
>>> On Wed, May 08, 2024 at 01:39:27PM +0100, Alejandro Vallejo wrote:
>>>
+rc = x86_topo_from_parts(>policy,
On 23/05/2024 17:50, Roger Pau Monné wrote:
> On Wed, May 08, 2024 at 01:39:25PM +0100, Alejandro Vallejo wrote:
>> Add a helper to populate topology leaves in the cpu policy from
>> threads/core and cores/package counts.
>>
>> No functional change, as it's not connected to anything yet.
>
>
On 27/05/2024 9:44 am, Jan Beulich wrote:
> On 24.05.2024 22:03, Andrew Cooper wrote:
>> generic_f?s() being static inline is the cause of lots of the complexity
>> between the common and arch-specific bitops.h
>>
>> They appear to be static inline for constant-folding reasons (ARM uses them
>>
On 28.05.2024 14:30, Andrew Cooper wrote:
> On 27/05/2024 2:37 pm, Jan Beulich wrote:
>> On 27.05.2024 15:27, Jan Beulich wrote:
>>> On 24.05.2024 22:03, Andrew Cooper wrote:
--- a/xen/arch/x86/include/asm/bitops.h
+++ b/xen/arch/x86/include/asm/bitops.h
@@ -432,12 +432,28 @@ static
From: Penny Zheng
We are doing foreign memory mapping for static shared memory, and
there is a great possibility that it could be super mapped.
But today, p2m_put_l3_page could not handle superpages.
This commits implements a new function p2m_put_l2_superpage to handle
level 2 superpages,
On 27.05.24 14:55, Ilpo Järvinen wrote:
xen_pcifront_enable_irq() uses pci_read_config_byte() that returns
PCIBIOS_* codes. The error handling, however, assumes the codes are
normal errnos because it checks for < 0.
xen_pcifront_enable_irq() also returns the PCIBIOS_* code back to the
caller
On 27/05/2024 09:52, Roger Pau Monné wrote:
>> My intent here was to prevent the compiler omitting the write (though in
>> practice it didn't). I think the barrier is still required to prevent
>> reordering according to the spec.
>
> Yes, my understating is that you added the ACCESS_ONCE() to
On 27/05/2024 2:37 pm, Jan Beulich wrote:
> On 27.05.2024 15:27, Jan Beulich wrote:
>> On 24.05.2024 22:03, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/bitops.h
>>> +++ b/xen/arch/x86/include/asm/bitops.h
>>> @@ -432,12 +432,28 @@ static inline int ffsl(unsigned long x)
>>>
>>>
Hello,
When the stop_machine_run() call in cpu_down() fails and calls the CPU
notifier CPU_DOWN_FAILED hook the following assert triggers in the
scheduling code:
Assertion '!cpumask_test_cpu(cpu, >initialized)' failed at
common/sched/cred1
[ Xen-4.19-unstable x86_64 debug=y Tainted: C
On 12/05/2024 3:48 pm, Andrew Cooper wrote:
> On 12/05/2024 3:16 am, Marek Marczykowski-Górecki wrote:
>> Hi,
>>
>> I've got a report[1] that after some update Linux HVM fails to start with the
>> error as in the subject. It looks to be caused by some change between
>> Xen 4.17.3 and 4.17.4. Here
flight 186165 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186165/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186133
test-amd64-amd64-libvirt 15
flight 186166 xen-unstable-smoke real [real]
flight 186167 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186166/
http://logs.test-lab.xenproject.org/osstest/logs/186167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 186163 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-build fail in 186157 REGR. vs. 186163
Tests which are
Update ECLAIR configuration to deviate more cases where an
unintentional fallthrough cannot happen.
Add Rule 16.3 to the monitored set and tag as clean for arm.
Signed-off-by: Federico Serafini
---
In previous discussions about Rule 16.3, the preference expressed was to deviate
cases where a
On 28.05.2024 10:37, Oleksii K. wrote:
> On Tue, 2024-05-28 at 08:20 +0200, Jan Beulich wrote:
>> On 24.05.2024 13:08, Oleksii Kurochko wrote:
>>> +/**
>>> + * generic_test_bit - Determine whether a bit is set
>>> + * @nr: bit number to test
>>> + * @addr: Address to start counting from
>>> + *
Hi Roger,
On 28/05/2024 08:11, Roger Pau Monné wrote:
On Mon, May 27, 2024 at 10:14:59PM +0100, Julien Grall wrote:
Hi Roger,
On 23/05/2024 08:55, Roger Pau Monné wrote:
On Wed, May 22, 2024 at 06:59:20PM -0400, Stewart Hildebrand wrote:
From: Volodymyr Babchuk
Guest can try to read
Hi Oleksii,
On 28/05/2024 09:37, Oleksii K. wrote:
On Tue, 2024-05-28 at 08:20 +0200, Jan Beulich wrote:
On 24.05.2024 13:08, Oleksii Kurochko wrote:
The following generic functions were introduced:
* test_bit
* generic__test_and_set_bit
* generic__test_and_clear_bit
*
On Tue, 2024-05-28 at 08:20 +0200, Jan Beulich wrote:
> On 24.05.2024 13:08, Oleksii Kurochko wrote:
> > The following generic functions were introduced:
> > * test_bit
> > * generic__test_and_set_bit
> > * generic__test_and_clear_bit
> > * generic__test_and_change_bit
> >
> > These functions and
Hi Julien,
> On 24 May 2024, at 13:56, Julien Grall wrote:
>
> Hi Luca,
>
> On 24/05/2024 13:40, Luca Fancellu wrote:
>> From: Penny Zheng
>> We are doing foreign memory mapping for static shared memory, and
>> there is a great possibility that it could be super mapped.
>> But today,
On Mon, May 27, 2024 at 10:14:59PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 23/05/2024 08:55, Roger Pau Monné wrote:
> > On Wed, May 22, 2024 at 06:59:20PM -0400, Stewart Hildebrand wrote:
> > > From: Volodymyr Babchuk
> > >
> > > Guest can try to read config space using different access
On 27.05.2024 16:53, Nicola Vetrini wrote:
> Rule 8.4 states: "A compatible declaration shall be visible when
> an object or function with external linkage is defined".
>
> The function do_general_protection is either used is asm code
> or only within this unit, so there is no risk of this
On 27.05.2024 16:53, Nicola Vetrini wrote:
> Rule 8.4 states: "A compatible declaration shall be visible when
> an object or function with external linkage is defined."
>
> These variables are only referenced from asm modules, so they
> need to be extern and there is negligible risk of them being
On 24.05.2024 13:08, Oleksii Kurochko wrote:
> The following generic functions were introduced:
> * test_bit
> * generic__test_and_set_bit
> * generic__test_and_clear_bit
> * generic__test_and_change_bit
>
> These functions and macros can be useful for architectures
> that don't have
61 matches
Mail list logo
