On 05.12.2023 18:24, René Winther Højgaard wrote:
> You are right about sched-gran=core being the issue.
>
> I don't know if this is relevant, but my CPU shouldn't be able to use
> sched-gran=core it's asymmetric.
>
> smt=on with sched-gran=core gives me a warning that it's falling back to
> sc
> > diff --git a/arch/x86/entry/entry_fred.c b/arch/x86/entry/entry_fred.c
> > new file mode 100644 index ..215883e90f94
> > --- /dev/null
> > +++ b/arch/x86/entry/entry_fred.c
> > @@ -0,0 +1,230 @@
> > ...
> > +static noinstr void fred_intx(struct pt_regs *regs) {
> > + switch (regs-
On 05.12.2023 16:55, Roger Pau Monné wrote:
> On Tue, Dec 05, 2023 at 03:59:13PM +0100, Jan Beulich wrote:
>> On 05.12.2023 15:29, Roger Pau Monné wrote:
>>> On Tue, Dec 05, 2023 at 09:52:31AM +0100, Jan Beulich wrote:
On 04.12.2023 18:27, Roger Pau Monné wrote:
> On Tue, Nov 28, 2023 at 1
flight 184004 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184004/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7e18c9a788e543ab71cdc0485989cf5d00cdccc2
baseline version:
ovmf ef3fde64aa78598a4c215
On 05.12.2023 18:29, Roger Pau Monné wrote:
> On Tue, Nov 28, 2023 at 11:35:46AM +0100, Jan Beulich wrote:
>> @@ -387,7 +387,7 @@ static int cf_check vpic_intercept_elcr_
>> if ( dir == IOREQ_WRITE )
>> {
>> /* Some IRs are always edge trig. Slave IR is always level
On Wed, Dec 06, 2023 at 02:56:05PM +0800, Yu Kuai wrote:
> > > - invalidate_inode_pages2(
> > > - blkif->vbd.bdev_handle->bdev->bd_inode->i_mapping);
> > > + invalidate_bdev(blkif->vbd.bdev_handle->bdev);
> >
> > blkbak is a bdev exported. I don't think it should ever call
> > in
On Wed, Dec 06, 2023 at 02:50:56PM +0800, Yu Kuai wrote:
> I'm a litter confused, so there are 3 use cases:
> 1) use GFP_USER, default gfp from bdev_alloc.
> 2) use GFP_KERNEL
> 3) use GFP_NOFS
>
> I understand that you're suggesting memalloc_nofs_save() to distinguish
> 2 and 3, but how can I dis
On 05.12.2023 21:31, Sébastien Chaumat wrote:
>> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
>
> Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
> ioapic-edge and IRQ9 to ioapic-level ?
>
> IR-IO-APIC7-fasteoi pinctrl_amd
> IR-IO-APIC9-fasteoi
Instead of defining get_unaligned() and put_unaligned() in a way that
is only supporting architectures allowing unaligned accesses, use the
same approach as the Linux kernel and let the compiler do the
decision how to generate the code for probably unaligned data accesses.
Update include/xen/unali
Update Xen's unaligned.h header to support all architectures, allowing
to remove the architecture specific variants (x86 only until now).
Changes in V2:
- new patch 1 (Julien Grall)
- adjusted patch 2 (Jan Beulich)
Juergen Gross (3):
xen/arm: set -mno-unaligned-access compiler option for Arm32
With include/xen/unaligned.h now dealing properly with unaligned
accesses for all architectures, asm/unaligned.h can be removed and
users can be switched to include xen/unaligned.h instead.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
xen/arch/x86/include/asm/unaligned.h | 6 --
As the hypervisor is disabling unaligned accesses for Arm32, set the
-mno-unaligned-access compiler option for building. This will prohibit
unaligned accesses when e.g. accessing 2- or 4-byte data items in
packed data structures.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
xen/arch/arm/
flight 184002 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184002/
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
Hi,
在 2023/12/06 13:55, Christoph Hellwig 写道:
On Tue, Dec 05, 2023 at 08:37:16PM +0800, Yu Kuai wrote:
diff --git a/drivers/block/xen-blkback/xenbus.c
b/drivers/block/xen-blkback/xenbus.c
index e34219ea2b05..e645afa4af57 100644
--- a/drivers/block/xen-blkback/xenbus.c
+++ b/drivers/block/xen-b
Hi,
在 2023/12/06 14:14, Christoph Hellwig 写道:
+void invalidate_bdev_range(struct block_device *bdev, pgoff_t start,
+ pgoff_t end)
+{
+ invalidate_mapping_pages(bdev->bd_inode->i_mapping, start, end);
+}
+EXPORT_SYMBOL_GPL(invalidate_bdev_range);
All these could
Hi Thomas Gleixner,
On 2023/12/6 01:02, Thomas Gleixner wrote:
> On Mon, Dec 04 2023 at 13:31, Stefano Stabellini wrote:
>> On Mon, 3 Dec 2023, Chen, Jiqian wrote:
> vpci device state when device is reset on dom0 side.
>
> And call that function in pcistub_init_device. Because when
>>>
> +void invalidate_bdev_range(struct block_device *bdev, pgoff_t start,
> +pgoff_t end)
> +{
> + invalidate_mapping_pages(bdev->bd_inode->i_mapping, start, end);
> +}
> +EXPORT_SYMBOL_GPL(invalidate_bdev_range);
All these could probably use kerneldoc comments.
For this
flight 183996 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183996/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183990
test-amd64-i386-xl-qemuu-win7-amd64
On 2023/12/5 18:32, Jan Beulich wrote:
> On 05.12.2023 10:19, Roger Pau Monné wrote:
>> On Mon, Dec 04, 2023 at 02:19:33PM -0800, Stefano Stabellini wrote:
>>> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
On Fri, Dec 01, 2023 at 07:37:55PM -0800, Stefano Stabellini wrote:
> On Fri, 1 Dec 202
Hi,
在 2023/12/06 13:54, Christoph Hellwig 写道:
On Tue, Dec 05, 2023 at 08:37:14PM +0800, Yu Kuai wrote:
From: Yu Kuai
Patch 1 add some bdev apis, then follow up patches will use these apis
to avoid access bd_inode directly, and hopefully the field bd_inode can
be removed eventually(after figur
On Tue, Dec 05, 2023 at 08:37:16PM +0800, Yu Kuai wrote:
> diff --git a/drivers/block/xen-blkback/xenbus.c
> b/drivers/block/xen-blkback/xenbus.c
> index e34219ea2b05..e645afa4af57 100644
> --- a/drivers/block/xen-blkback/xenbus.c
> +++ b/drivers/block/xen-blkback/xenbus.c
> @@ -104,8 +104,7 @@ st
On Tue, Dec 05, 2023 at 08:37:14PM +0800, Yu Kuai wrote:
> From: Yu Kuai
>
> Patch 1 add some bdev apis, then follow up patches will use these apis
> to avoid access bd_inode directly, and hopefully the field bd_inode can
> be removed eventually(after figure out a way for fs/buffer.c).
What tree
Pipeline #1096802796 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 3e5672d6 (
https://gitlab.com/xen-project/xen/-/commit/3e5672d69fe09e240195fa6744686b59db6d7d69
)
Commit Message: automation/ec
On Tue, 5 Dec 2023, Federico Serafini wrote:
> Add missing parameter names to address violations of MISRA C:2012
> Rule 8.2. Furthermore, use C standard types to comply with XEN coding style.
> No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Tue, 5 Dec 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Tue, 5 Dec 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Tue, 5 Dec 2023, Federico Serafini wrote:
> Add missing parameter names to address violations of MISRA C:2012
> Rule 8.2. Furthermore, remove trailing spaces and use C standard types to
> comply with XEN coding style.
>
> No functional change.
>
> Signed-off-by: Federico Serafini
> ---
> xen
On Tue, 5 Dec 2023, Federico Serafini wrote:
> Add missing parameter names. No functional change.
>
> Signed-off-by: Federico Serafini
> ---
> xen/arch/x86/include/asm/mm.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/xen/arch/x86/include/asm/m
On Tue, 5 Dec 2023, Federico Serafini wrote:
> Add missing parameter names to address violations of MISRA C:2012
> Rule 8.2. Furthermore, use C standard types to comply with XEN coding style.
>
> No functional change.
>
> Signed-off-by: Federico Serafini
> ---
> xen/arch/x86/include/asm/acpi.h
Thank you for your prompt response.
On Tue, Dec 5, 2023 at 11:43 PM Andrew Cooper wrote:
> Who is still in 64-bit mode ?
>
> It is legal for a 64-bit L1 to VMRUN into a 32-bit L2 with PG=0.
>
> But I'm guessing that you mean L2 is also 64-bit, and we're clearing PG,
> thus creating an illegal sta
Add the rules accepted in the last three MISRA C working group meetings.
Signed-off-by: Stefano Stabellini
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 75921b9a34..ab89116a43 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -462,11 +462,23 @@ maintainers if you w
On Tue, 5 Dec 2023, Luca Fancellu wrote:
> Hi all,
>
> I’m writing this mail to collect thoughts about the need to improve the SAF-*
> comments.
>
> I think we reached a point where we need to use deviations for some violation
> that we want
> to keep in the code with a proper justification and
On Tue, 5 Dec 2023, Roger Pau Monné wrote:
> > > > I don't think we should enable IOREQ servers to handle PCI passthrough
> > > > for PVH guests and/or guests with vPCI. If the domain has vPCI, PCI
> > > > Passthrough can be handled by vPCI just fine. I think this should be a
> > > > good anti-feat
On Tue, Dec 5, 2023 at 2:07 PM Jan Beulich wrote:
>
> On 05.12.2023 14:46, Luca Fancellu wrote:
> > In my opinion, I don’t know of any tool that can address all the
> > flexibility the Xen codestyle allows, yet the use of automatic
> > checkers would improve the review time, allow more new contri
On Tue, Dec 5, 2023 at 6:12 PM Julien Grall wrote:
>
> From: Julien Grall
>
> Several maintainers have expressed a stronger preference
> to use '-' when in filename and option that contains multiple
> words.
>
> So document it in CODING_STYLE.
>
> Signed-off-by: Julien Grall
>
> ---
> Change
flight 183993 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183993/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 183973
Tests which did not
flight 184000 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184000/
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
Pipeline #1096652606 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 4c6142a1 (
https://gitlab.com/xen-project/xen/-/commit/4c6142a1ab004be132f386da3cabce07b44fac2d
)
Commit Message: CI: Fix fallo
flight 183999 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183999/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ef3fde64aa78598a4c21556629936fb228390e8c
baseline version:
ovmf 120aa6064465496c962b6
On Tue, 5 Dec 2023, Stewart Hildebrand wrote:
> On 12/5/23 12:09, Roger Pau Monné wrote:
> > On Tue, Dec 05, 2023 at 11:27:03AM -0500, Stewart Hildebrand wrote:
> >> On 12/5/23 06:08, Roger Pau Monné wrote:
> >>> On Mon, Dec 04, 2023 at 02:07:51PM -0800, Stefano Stabellini wrote:
> On Mon, 4 D
On Tue, 5 Dec 2023, Julien Grall wrote:
> Hi Ayan,
>
> On 05/12/2023 12:50, Ayan Kumar Halder wrote:
> > Hi Julien/All,
> >
> > On 05/12/2023 11:02, Michal Orzel wrote:
> > >
> > > On 05/12/2023 11:42, Julien Grall wrote:
> > > >
> > > > On 05/12/2023 10:30, Michal Orzel wrote:
> > > > >
> > >
On Tue, 5 Dec 2023, Andrew Cooper wrote:
> Commit 948e03303138 ("automation/alpine: add elfutils-dev") had an unintended
> consequence of causing Qemu to gain a runtime dependency on libdw.so
>
> The {adl,zen3p}-pci-hvm-x86-64-gcc-debug tests, which are the only two tests
> that run the built Qemu
Pipeline #1096532827 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 01da0aee (
https://gitlab.com/xen-project/xen/-/commit/01da0aeecd41435cea8bd2fe0f547e0a474f6e45
)
Commit Message: ns16550: remo
Commit 948e03303138 ("automation/alpine: add elfutils-dev") had an unintended
consequence of causing Qemu to gain a runtime dependency on libdw.so
The {adl,zen3p}-pci-hvm-x86-64-gcc-debug tests, which are the only two tests
that run the built Qemu, started failing with:
Error loading shared lib
Pipeline #1096532827 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 01da0aee (
https://gitlab.com/xen-project/xen/-/commit/01da0aeecd41435cea8bd2fe0f547e0a474f6e45
)
Commit Message: ns16550: remo
On Tue, 5 Dec 2023, Jan Beulich wrote:
> The rule demands that all array elements be initialized (or dedicated
> initializers be used). Introduce a small set of macros to allow doing so
> without unduly affecting use sites (in particular in terms of how many
> elements .matches[] actually has; righ
Pipeline #1096532827 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 01da0aee (
https://gitlab.com/xen-project/xen/-/commit/01da0aeecd41435cea8bd2fe0f547e0a474f6e45
)
Commit Message: ns16550: remo
Pipeline #1096471389 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 948e0330 (
https://gitlab.com/xen-project/xen/-/commit/948e03303138482bf12f67740d8ebd8272824903
)
Commit Message: automation/al
On Tue, 4 Dec 2023, Juergen Gross wrote:
> Update the Xen PV-device interface headers in order to avoid undefined
> behavior with flexible arrays being defined with one array element.
>
> Reported-by: Pry Mar
> Signed-off-by: Juergen Gross
Acked-by: Stefano Stabellini
> ---
> include/xen/int
flight 183998 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183998/
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
Pipeline #1096471389 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 948e0330 (
https://gitlab.com/xen-project/xen/-/commit/948e03303138482bf12f67740d8ebd8272824903
)
Commit Message: automation/al
Pipeline #1096471389 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 948e0330 (
https://gitlab.com/xen-project/xen/-/commit/948e03303138482bf12f67740d8ebd8272824903
)
Commit Message: automation/al
Pipeline #1096471389 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 948e0330 (
https://gitlab.com/xen-project/xen/-/commit/948e03303138482bf12f67740d8ebd8272824903
)
Commit Message: automation/al
Pipeline #1096471389 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 948e0330 (
https://gitlab.com/xen-project/xen/-/commit/948e03303138482bf12f67740d8ebd8272824903
)
Commit Message: automation/al
Pipeline #1096471389 has failed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: 948e0330 (
https://gitlab.com/xen-project/xen/-/commit/948e03303138482bf12f67740d8ebd8272824903
)
Commit Message: automation/al
Hi Andrew,
On 05/12/2023 19:49, Andrew Cooper wrote:
On 05/12/2023 6:32 pm, Julien Grall wrote:
diff --git a/xen/Makefile b/xen/Makefile
index ca571103c868..360fb6dcae57 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -393,6 +393,7 @@ CFLAGS-$(CONFIG_CC_SPLIT_SECTIONS) += -ffunction-sections
-
> [2.464598] amd_gpio AMDI0030:00: failed to enable wake-up interrupt
Is it expected that IRQ7 goes from fasteoi (kernel 6.6.4 ) to
ioapic-edge and IRQ9 to ioapic-level ?
IR-IO-APIC7-fasteoi pinctrl_amd
IR-IO-APIC9-fasteoi acpi
to (xen 4.18.0)
xen-pirq -ioapic-edge pinctrl_
On 05/12/2023 4:31 pm, Nicola Vetrini wrote:
> The initializer of 'ns16550_com' violates MISRA C Rule 9.3
> because it explicitly initializes only the first element of the array,
> but the semantics is the same if the explicit initialization is
> omitted.
>
> No functional change.
>
> Signed-off-by
flight 183992 libvirt real [real]
flight 183997 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183992/
http://logs.test-lab.xenproject.org/osstest/logs/183997/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-li
On 05/12/2023 6:32 pm, Julien Grall wrote:
> diff --git a/xen/Makefile b/xen/Makefile
> index ca571103c868..360fb6dcae57 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -393,6 +393,7 @@ CFLAGS-$(CONFIG_CC_SPLIT_SECTIONS) += -ffunction-sections
> -fdata-sections
>
> CFLAGS += -nostdinc -fn
> > +static noinstr void fred_intx(struct pt_regs *regs) {
> > + switch (regs->fred_ss.vector) {
> > + /* INT0 */
>
> INTO (for overflow), not INT-zero. However...
>
> > + case X86_TRAP_OF:
> > + exc_overflow(regs);
> > + return;
> > +
> > + /* INT3 */
> > + case X8
On 12/5/23 06:08, Roger Pau Monné wrote:
> On Mon, Dec 04, 2023 at 02:07:51PM -0800, Stefano Stabellini wrote:
>> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
>>> On Fri, Dec 01, 2023 at 06:56:32PM -0800, Stefano Stabellini wrote:
On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> On Mon, Nov 13,
Hi Alexander.
On 04/12/2023 09:28, Alexander Kanavin wrote:
On 12/1/23 20:14, Julien Grall wrote:
So I agree that if we were to remove -Wdeclaration-after-statement
then we should also update the CODING_STYLE. However, I am not
entirely sure I would want to mix code and declaration in the hy
The AioContext lock no longer exists.
There is one noteworthy change:
- * More specifically, these functions use BDRV_POLL_WHILE(bs), which
- * requires the caller to be either in the main thread and hold
- * the BlockdriverState (bs) AioContext lock, or directly in the
- * home thread th
From: Julien Grall
Right now, all tools and hypervisor will be complied with the option
-Wdeclaration-after-statement. While most of the code in the hypervisor
is controlled by us, for tools we may import external libraries.
The build will fail if one of them are using the construct we are
tryin
The AioContext lock no longer exists.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
include/qemu/job.h | 20
1 file changed, 20 deletions(-)
diff --git a/include/qemu/job.h b/include/qemu/job.h
index e502787dd8..9ea98b5927 100644
--- a/include/qemu/job.h
+++ b
Encourage the use of locking primitives and stop mentioning the
AioContext lock since it is being removed.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
docs/devel/multiple-iothreads.txt | 45 +++
1 file changed, 15 insertions(+), 30 deletions(-)
diff -
Delete these functions because nothing calls these functions anymore.
I introduced these APIs in commit 98563fc3ec44 ("aio: add
aio_context_acquire() and aio_context_release()") in 2014. It's with a
sigh of relief that I delete these APIs almost 10 years later.
Thanks to Paolo Bonzini's vision fo
The bdrv_co_lock() and bdrv_co_unlock() functions are already no-ops.
Remove them.
Signed-off-by: Stefan Hajnoczi
---
include/block/block-global-state.h | 14 --
block.c| 10 --
blockdev.c | 4
3 files changed, 28 dele
The SCSI subsystem no longer uses the AioContext lock. Request
processing runs exclusively in the BlockBackend's AioContext since
"scsi: only access SCSIDevice->requests from one thread" and hence the
lock is unnecessary.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
hw/scsi/scsi-d
Stop acquiring/releasing the AioContext lock in
bdrv_graph_wrlock()/bdrv_graph_unlock() since the lock no longer has any
effect.
The distinction between bdrv_graph_wrunlock() and
bdrv_graph_wrunlock_ctx() becomes meaningless and they can be collapsed
into one function.
Signed-off-by: Stefan Hajno
Now that the AioContext lock no longer exists, AIO_WAIT_WHILE() and
AIO_WAIT_WHILE_UNLOCKED() are equivalent.
A future patch will get rid of AIO_WAIT_WHILE_UNLOCKED().
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
include/block/aio-wait.h | 16
1 file changed, 4 i
The aio_context_acquire() API is being removed. Drop the test case that
calls the API.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
Reviewed-by: Kevin Wolf
---
tests/unit/test-aio.c | 67 +--
1 file changed, 1 insertion(+), 66 deletions(-)
dif
The AioContext lock no longer has any effect. Remove it.
Signed-off-by: Stefan Hajnoczi
Reviewed-by: Eric Blake
---
include/hw/virtio/virtio-scsi.h | 14 --
hw/scsi/scsi-bus.c | 2 --
hw/scsi/scsi-disk.c | 31 +--
hw/scsi/virtio-
Since the removal of AioContext locking, the correctness of the code
relies on running requests from a single AioContext at any given time.
Add assertions that verify that callbacks are invoked in the correct
AioContext.
Signed-off-by: Stefan Hajnoczi
---
hw/scsi/scsi-disk.c | 14 +
aio_context_acquire()/aio_context_release() has been replaced by
fine-grained locking to protect state shared by multiple threads. The
AioContext lock still plays the role of balancing locking in
AIO_WAIT_WHILE() and many functions in QEMU either require that the
AioContext lock is held or not held
Protect the Task Management Function BH state with a lock. The TMF BH
runs in the main loop thread. An IOThread might process a TMF at the
same time as the TMF BH is running. Therefore tmf_bh_list and tmf_bh
must be protected by a lock.
Run TMF request completion in the IOThread using aio_wait_bh_
v2:
- Add Patch 2 "scsi: assert that callbacks run in the correct AioContext"
[Kevin]
- Add Patch 7 "block: remove bdrv_co_lock()" [Eric and Kevin]
- Remove stray goto label in Patch 8 [Kevin]
- Fix "eeked" -> "eked" typo in Patch 10 [Eric]
This series removes the AioContext locking APIs from QEM
From: Julien Grall
Several maintainers have expressed a stronger preference
to use '-' when in filename and option that contains multiple
words.
So document it in CODING_STYLE.
Signed-off-by: Julien Grall
---
Changes in v2:
- New wording
- Update the section title
On Tue, Nov 28, 2023 at 11:36:40AM +0100, Jan Beulich wrote:
> Loading is_master from the state save record can lead to out-of-bounds
> accesses via at least the two container_of() uses by vpic_domain() and
> __vpic_lock(). Make sure the value is consistent with the instance being
> loaded.
>
> Fo
On 12/5/23 12:09, Roger Pau Monné wrote:
> On Tue, Dec 05, 2023 at 11:27:03AM -0500, Stewart Hildebrand wrote:
>> On 12/5/23 06:08, Roger Pau Monné wrote:
>>> On Mon, Dec 04, 2023 at 02:07:51PM -0800, Stefano Stabellini wrote:
On Mon, 4 Dec 2023, Roger Pau Monné wrote:
> On Fri, Dec 01, 20
On Tue, Nov 28, 2023 at 11:35:46AM +0100, Jan Beulich wrote:
> Master bit 2 is treated specially: We force it set, but we don't expose
> the bit being set to the guest. While right now the read and write
> handling can easily use the fixed mask, the restore input checking that
> is about to be put
You are right about sched-gran=core being the issue.
I don't know if this is relevant, but my CPU shouldn't be able to use
sched-gran=core it's asymmetric.
smt=on with sched-gran=core gives me a warning that it's falling back to
sched-gran=cpu, I tested smt=off with sched-gran=cpu and it works.
On Tue, Dec 05, 2023 at 11:27:03AM -0500, Stewart Hildebrand wrote:
> On 12/5/23 06:08, Roger Pau Monné wrote:
> > On Mon, Dec 04, 2023 at 02:07:51PM -0800, Stefano Stabellini wrote:
> >> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
> >>> On Fri, Dec 01, 2023 at 06:56:32PM -0800, Stefano Stabellini w
On 12/5/23 04:37, Yu Kuai wrote:
+static inline u8 block_bits(struct block_device *bdev)
+{
+ return bdev->bd_inode->i_blkbits;
+}
This function needs a name that's more descriptive.
Thanks,
Bart.
On Mon, Dec 04 2023 at 13:31, Stefano Stabellini wrote:
> On Mon, 3 Dec 2023, Chen, Jiqian wrote:
>> >> vpci device state when device is reset on dom0 side.
>> >>
>> >> And call that function in pcistub_init_device. Because when
>> >> we use "pci-assignable-add" to assign a passthrough device in
>>
On 05.12.23 17:29, Julien Grall wrote:
Hi Arnd,
On 05/12/2023 14:37, Arnd Bergmann wrote:
On Tue, Dec 5, 2023, at 15:19, Julien Grall wrote:
On 05/12/2023 14:10, Arnd Bergmann wrote:
On Tue, Dec 5, 2023, at 15:01, Julien Grall wrote:
On 05/12/2023 13:59, Jan Beulich wrote:
On 05.12.2023 14:
The initializer of 'ns16550_com' violates MISRA C Rule 9.3
because it explicitly initializes only the first element of the array,
but the semantics is the same if the explicit initialization is
omitted.
No functional change.
Signed-off-by: Nicola Vetrini
---
In the context of the rule ("Arrays s
Hi Arnd,
On 05/12/2023 14:37, Arnd Bergmann wrote:
On Tue, Dec 5, 2023, at 15:19, Julien Grall wrote:
On 05/12/2023 14:10, Arnd Bergmann wrote:
On Tue, Dec 5, 2023, at 15:01, Julien Grall wrote:
On 05/12/2023 13:59, Jan Beulich wrote:
On 05.12.2023 14:46, Julien Grall wrote:
This would repe
On 12/5/23 06:08, Roger Pau Monné wrote:
> On Mon, Dec 04, 2023 at 02:07:51PM -0800, Stefano Stabellini wrote:
>> On Mon, 4 Dec 2023, Roger Pau Monné wrote:
>>> On Fri, Dec 01, 2023 at 06:56:32PM -0800, Stefano Stabellini wrote:
On Fri, 1 Dec 2023, Roger Pau Monné wrote:
> On Mon, Nov 13,
Hi Jan,
On 2023-12-05 14:35, Jan Beulich wrote:
The rule demands that all array elements be initialized (or dedicated
initializers be used). Introduce a small set of macros to allow doing
so
without unduly affecting use sites (in particular in terms of how many
elements .matches[] actually has
Le mar. 5 déc. 2023 à 15:18, Jan Beulich a écrit :
>
> On 05.12.2023 15:14, Sébastien Chaumat wrote:
> > booting kernel with "dyndbg=file drivers/gpio/* +p"
>
> I'm afraid this doesn't tell me anything. I'm simply not familiar with
> Linux'es GPIO handling.
>
Thanks for your help so far.
I moved
On Tue, Dec 05, 2023 at 04:47:15PM +0100, Jan Beulich wrote:
> On 05.12.2023 16:43, Roger Pau Monné wrote:
> > On Tue, Dec 05, 2023 at 04:27:05PM +0100, Jan Beulich wrote:
> >> On 04.12.2023 10:43, Roger Pau Monne wrote:
> >>> @@ -476,58 +406,55 @@ void __hwdom_init arch_iommu_hwdom_init(struct
>
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/public/arch-riscv/hvm/save.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Structure definitions for HVM state that is held by Xen and must
> + * be saved along with the domain's memory and devic
On 12/1/23 20:27, Volodymyr Babchuk wrote:
> Introduce "fail" label in init_bars() function to have the centralized
The name was correct at the time of submission, but since then, init_bars() was
renamed to init_header() in staging
> error return path. This is the pre-requirement for the future
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/fence.h
> @@ -0,0 +1,12 @@
> +#ifndef _ASM_RISCV_FENCE_H
> +#define _ASM_RISCV_FENCE_H
> +
> +#ifdef CONFIG_SMP
> +#define RISCV_ACQUIRE_BARRIER"\tfence r , rw\n"
> +#define RISCV_RELEASE
On Tue, Dec 05, 2023 at 03:59:13PM +0100, Jan Beulich wrote:
> On 05.12.2023 15:29, Roger Pau Monné wrote:
> > On Tue, Dec 05, 2023 at 09:52:31AM +0100, Jan Beulich wrote:
> >> On 04.12.2023 18:27, Roger Pau Monné wrote:
> >>> On Tue, Nov 28, 2023 at 11:34:04AM +0100, Jan Beulich wrote:
> ...,
On 24.11.2023 11:30, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
flight 183990 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183990/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 183983
test-amd64-i386-xl-qemuu-win7-amd64
On 05.12.2023 16:48, Roger Pau Monné wrote:
> On Tue, Dec 05, 2023 at 04:29:18PM +0100, Jan Beulich wrote:
>> On 04.12.2023 10:43, Roger Pau Monne wrote:
>>> Remove xen_in_range() and vpci_is_mmcfg_address() now that hey are unused.
>>
>> Of the latter you remove only the declaration. Stale patch m
1 - 100 of 247 matches
Mail list logo
