* [PATCH kvm-unit-tests] realmode: load above stack @ 2024-06-04 14:35 Paolo Bonzini 2024-06-04 14:40 ` Thomas Huth 2026-05-04 7:58 ` Thomas Huth 0 siblings, 2 replies; 20+ messages in thread From: Paolo Bonzini @ 2024-06-04 14:35 UTC (permalink / raw) To: kvm; +Cc: thuth The bottom 32K of memory are generally reserved for use by the BIOS; for example, traditionally the boot loader is placed at 0x7C00 and the stack grows below that address. It turns out that with some versions of clang, realmode.flat has become big enough that it overlaps the stack used by the multiboot option ROM loader. The result is that a couple instructions are overwritten. Typically one or two tests fail and that's it... Move the code above the forbidden region, in real 90s style. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- x86/realmode.lds | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x86/realmode.lds b/x86/realmode.lds index 0ed3063b..e4782a98 100644 --- a/x86/realmode.lds +++ b/x86/realmode.lds @@ -1,6 +1,6 @@ SECTIONS { - . = 16K; + . = 32K; stext = .; .text : { *(.init) *(.text) } . = ALIGN(4K); -- 2.45.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH kvm-unit-tests] realmode: load above stack 2024-06-04 14:35 [PATCH kvm-unit-tests] realmode: load above stack Paolo Bonzini @ 2024-06-04 14:40 ` Thomas Huth 2024-06-04 14:50 ` Paolo Bonzini 2026-05-04 7:58 ` Thomas Huth 1 sibling, 1 reply; 20+ messages in thread From: Thomas Huth @ 2024-06-04 14:40 UTC (permalink / raw) To: Paolo Bonzini, kvm On 04/06/2024 16.35, Paolo Bonzini wrote: > The bottom 32K of memory are generally reserved for use by the BIOS; > for example, traditionally the boot loader is placed at 0x7C00 and > the stack grows below that address. > > It turns out that with some versions of clang, realmode.flat has > become big enough that it overlaps the stack used by the multiboot > option ROM loader. The result is that a couple instructions are > overwritten. Typically one or two tests fail and that's it... > > Move the code above the forbidden region, in real 90s style. > > Reported-by: Thomas Huth <thuth@redhat.com> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > x86/realmode.lds | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/x86/realmode.lds b/x86/realmode.lds > index 0ed3063b..e4782a98 100644 > --- a/x86/realmode.lds > +++ b/x86/realmode.lds > @@ -1,6 +1,6 @@ > SECTIONS > { > - . = 16K; > + . = 32K; > stext = .; > .text : { *(.init) *(.text) } > . = ALIGN(4K); This fails for me with: ld -m elf_i386 -nostdlib -o x86/realmode.elf \ -T /home/thuth/devel/kvm-unit-tests/x86/realmode.lds x86/realmode.o x86/realmode.o: in function `init_inregs': /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0x79): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0x82): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0x8b): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0x94): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0x9d): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0xa6): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0xaf): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0xb8): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0xc1): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:176:(.text+0xca): relocation truncated to fit: R_386_16 against `.bss' /home/thuth/devel/kvm-unit-tests/x86/realmode.c:180:(.text+0xda): additional relocation overflows omitted from the output make: *** [/home/thuth/devel/kvm-unit-tests/x86/Makefile.common:107: x86/realmode.elf] Error 1 Thomas ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH kvm-unit-tests] realmode: load above stack 2024-06-04 14:40 ` Thomas Huth @ 2024-06-04 14:50 ` Paolo Bonzini 0 siblings, 0 replies; 20+ messages in thread From: Paolo Bonzini @ 2024-06-04 14:50 UTC (permalink / raw) To: Thomas Huth; +Cc: kvm On Tue, Jun 4, 2024 at 4:40 PM Thomas Huth <thuth@redhat.com> wrote: > This fails for me with: Ok... I'll try building a fully relocated binary and copying it to the right address. Paolo ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH kvm-unit-tests] realmode: load above stack 2024-06-04 14:35 [PATCH kvm-unit-tests] realmode: load above stack Paolo Bonzini 2024-06-04 14:40 ` Thomas Huth @ 2026-05-04 7:58 ` Thomas Huth 2026-05-04 8:07 ` intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) Thomas Huth 1 sibling, 1 reply; 20+ messages in thread From: Thomas Huth @ 2026-05-04 7:58 UTC (permalink / raw) To: Paolo Bonzini, kvm On 04/06/2024 16.35, Paolo Bonzini wrote: > The bottom 32K of memory are generally reserved for use by the BIOS; > for example, traditionally the boot loader is placed at 0x7C00 and > the stack grows below that address. > > It turns out that with some versions of clang, realmode.flat has > become big enough that it overlaps the stack used by the multiboot > option ROM loader. The result is that a couple instructions are > overwritten. Typically one or two tests fail and that's it... > > Move the code above the forbidden region, in real 90s style. > > Reported-by: Thomas Huth <thuth@redhat.com> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > x86/realmode.lds | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/x86/realmode.lds b/x86/realmode.lds > index 0ed3063b..e4782a98 100644 > --- a/x86/realmode.lds > +++ b/x86/realmode.lds > @@ -1,6 +1,6 @@ > SECTIONS > { > - . = 16K; > + . = 32K; > stext = .; > .text : { *(.init) *(.text) } > . = ALIGN(4K); Hi Paolo! FYI, the realmode kvm-unit-test now also fails with the recent version of GCC 16 for the i386 target: https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727 It was working fine some weeks ago with GCC 15.1: https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961 When I apply your patch, the problem seems to be gone again in this case, but since there were some other issues with this (with older versions of GCC, I think): https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/ ... there must be a better way to fix it? Could you please have a look? Thanks, Thomas ^ permalink raw reply [flat|nested] 20+ messages in thread
* intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) 2026-05-04 7:58 ` Thomas Huth @ 2026-05-04 8:07 ` Thomas Huth 2026-05-04 15:45 ` Peter Xu 0 siblings, 1 reply; 20+ messages in thread From: Thomas Huth @ 2026-05-04 8:07 UTC (permalink / raw) To: Paolo Bonzini, kvm; +Cc: Peter Xu On 04/05/2026 09.58, Thomas Huth wrote: > On 04/06/2024 16.35, Paolo Bonzini wrote: >> The bottom 32K of memory are generally reserved for use by the BIOS; >> for example, traditionally the boot loader is placed at 0x7C00 and >> the stack grows below that address. >> >> It turns out that with some versions of clang, realmode.flat has >> become big enough that it overlaps the stack used by the multiboot >> option ROM loader. The result is that a couple instructions are >> overwritten. Typically one or two tests fail and that's it... >> >> Move the code above the forbidden region, in real 90s style. >> >> Reported-by: Thomas Huth <thuth@redhat.com> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >> --- >> x86/realmode.lds | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/x86/realmode.lds b/x86/realmode.lds >> index 0ed3063b..e4782a98 100644 >> --- a/x86/realmode.lds >> +++ b/x86/realmode.lds >> @@ -1,6 +1,6 @@ >> SECTIONS >> { >> - . = 16K; >> + . = 32K; >> stext = .; >> .text : { *(.init) *(.text) } >> . = ALIGN(4K); > > Hi Paolo! > > FYI, the realmode kvm-unit-test now also fails with the recent version of > GCC 16 for the i386 target: > > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727 > > It was working fine some weeks ago with GCC 15.1: > > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961 > > When I apply your patch, the problem seems to be gone again in this case, > but since there were some other issues with this (with older versions of > GCC, I think): > > https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/ > > ... there must be a better way to fix it? > > Could you please have a look? By the way, the intel_iommu test now also suddenly started failing (for the x86_64 target), either due to update of GCC or due to the update from QEMU v10.2 to 11.0 : https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728 Two weeks ago, it was still working fine: https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962 Thomas ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) 2026-05-04 8:07 ` intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) Thomas Huth @ 2026-05-04 15:45 ` Peter Xu 2026-05-05 5:49 ` Clément MATHIEU--DRIF 0 siblings, 1 reply; 20+ messages in thread From: Peter Xu @ 2026-05-04 15:45 UTC (permalink / raw) To: Thomas Huth Cc: Paolo Bonzini, kvm, Yi Liu, Clément Mathieu--Drif, Michael S. Tsirkin On Mon, May 04, 2026 at 10:07:25AM +0200, Thomas Huth wrote: > On 04/05/2026 09.58, Thomas Huth wrote: > > On 04/06/2024 16.35, Paolo Bonzini wrote: > > > The bottom 32K of memory are generally reserved for use by the BIOS; > > > for example, traditionally the boot loader is placed at 0x7C00 and > > > the stack grows below that address. > > > > > > It turns out that with some versions of clang, realmode.flat has > > > become big enough that it overlaps the stack used by the multiboot > > > option ROM loader. The result is that a couple instructions are > > > overwritten. Typically one or two tests fail and that's it... > > > > > > Move the code above the forbidden region, in real 90s style. > > > > > > Reported-by: Thomas Huth <thuth@redhat.com> > > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > > > --- > > > x86/realmode.lds | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/x86/realmode.lds b/x86/realmode.lds > > > index 0ed3063b..e4782a98 100644 > > > --- a/x86/realmode.lds > > > +++ b/x86/realmode.lds > > > @@ -1,6 +1,6 @@ > > > SECTIONS > > > { > > > - . = 16K; > > > + . = 32K; > > > stext = .; > > > .text : { *(.init) *(.text) } > > > . = ALIGN(4K); > > > > Hi Paolo! > > > > FYI, the realmode kvm-unit-test now also fails with the recent version > > of GCC 16 for the i386 target: > > > > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727 > > > > It was working fine some weeks ago with GCC 15.1: > > > > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961 > > > > When I apply your patch, the problem seems to be gone again in this > > case, but since there were some other issues with this (with older > > versions of GCC, I think): > > > > https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/ > > > > ... there must be a better way to fix it? > > > > Could you please have a look? > > By the way, the intel_iommu test now also suddenly started failing (for the > x86_64 target), either due to update of GCC or due to the update from QEMU > v10.2 to 11.0 : > > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728 > > Two weeks ago, it was still working fine: > > https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962 Looping in those who take care of qemu's VT-D now (Yi, Clément).. -- Peter Xu ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) 2026-05-04 15:45 ` Peter Xu @ 2026-05-05 5:49 ` Clément MATHIEU--DRIF 2026-05-05 6:37 ` Clément MATHIEU--DRIF 0 siblings, 1 reply; 20+ messages in thread From: Clément MATHIEU--DRIF @ 2026-05-05 5:49 UTC (permalink / raw) To: Peter Xu, Thomas Huth Cc: Paolo Bonzini, kvm@vger.kernel.org, Yi Liu, Michael S. Tsirkin Hi, Indeed, it seems to start failing when switching to gcc 16.1. gcc 15.2.1 - Qemu 11 => pass gcc 16.1 - Qemu 11 => fail On Mon, 2026-05-04 at 11:45 -0400, Peter Xu wrote: > Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. > > > On Mon, May 04, 2026 at 10:07:25AM +0200, Thomas Huth wrote: > > > On 04/05/2026 09.58, Thomas Huth wrote: > > > > > On 04/06/2024 16.35, Paolo Bonzini wrote: > > > > > > > The bottom 32K of memory are generally reserved for use by the BIOS; > > > > for example, traditionally the boot loader is placed at 0x7C00 and > > > > the stack grows below that address. > > > > > > > > It turns out that with some versions of clang, realmode.flat has > > > > become big enough that it overlaps the stack used by the multiboot > > > > option ROM loader. The result is that a couple instructions are > > > > overwritten. Typically one or two tests fail and that's it... > > > > > > > > Move the code above the forbidden region, in real 90s style. > > > > > > > > Reported-by: Thomas Huth <[thuth@redhat.com](mailto:thuth@redhat.com)> > > > > Signed-off-by: Paolo Bonzini <[pbonzini@redhat.com](mailto:pbonzini@redhat.com)> > > > > --- > > > > x86/realmode.lds | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/x86/realmode.lds b/x86/realmode.lds > > > > index 0ed3063b..e4782a98 100644 > > > > --- a/x86/realmode.lds > > > > +++ b/x86/realmode.lds > > > > @@ -1,6 +1,6 @@ > > > > SECTIONS > > > > { > > > > - . = 16K; > > > > + . = 32K; > > > > stext = .; > > > > .text : { *(.init) *(.text) } > > > > . = ALIGN(4K); > > > > > > > > > Hi Paolo! > > > > > > FYI, the realmode kvm-unit-test now also fails with the recent version > > > of GCC 16 for the i386 target: > > > > > > [https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727) > > > > > > It was working fine some weeks ago with GCC 15.1: > > > > > > [https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961) > > > > > > When I apply your patch, the problem seems to be gone again in this > > > case, but since there were some other issues with this (with older > > > versions of GCC, I think): > > > > > > [https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/) > > > > > > ... there must be a better way to fix it? > > > > > > Could you please have a look? > > > > > > By the way, the intel_iommu test now also suddenly started failing (for the > > x86_64 target), either due to update of GCC or due to the update from QEMU > > v10.2 to 11.0 : > > > > [https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728) > > > > Two weeks ago, it was still working fine: > > > > [https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962) > > > Looping in those who take care of qemu's VT-D now (Yi, Clément).. > > -- > Peter Xu > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) 2026-05-05 5:49 ` Clément MATHIEU--DRIF @ 2026-05-05 6:37 ` Clément MATHIEU--DRIF 2026-05-05 7:36 ` Clément MATHIEU--DRIF 0 siblings, 1 reply; 20+ messages in thread From: Clément MATHIEU--DRIF @ 2026-05-05 6:37 UTC (permalink / raw) To: Peter Xu, Thomas Huth Cc: Paolo Bonzini, kvm@vger.kernel.org, Yi Liu, Michael S. Tsirkin I will try to investigate today, it seems that the host does not wait for the dma operation to complete before reading back. keep you posted cmd On Tue, 2026-05-05 at 07:49 +0200, Clement Mathieu--Drif wrote: > Hi, > > Indeed, it seems to start failing when switching to gcc 16.1. > > gcc 15.2.1 - Qemu 11 => pass > gcc 16.1 - Qemu 11 => fail > > On Mon, 2026-05-04 at 11:45 -0400, Peter Xu wrote: > > > Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. > > > > > > On Mon, May 04, 2026 at 10:07:25AM +0200, Thomas Huth wrote: > > > > > > > On 04/05/2026 09.58, Thomas Huth wrote: > > > > > > > > > > On 04/06/2024 16.35, Paolo Bonzini wrote: > > > > > > > > > > > > > The bottom 32K of memory are generally reserved for use by the BIOS; > > > > > for example, traditionally the boot loader is placed at 0x7C00 and > > > > > the stack grows below that address. > > > > > > > > > > It turns out that with some versions of clang, realmode.flat has > > > > > become big enough that it overlaps the stack used by the multiboot > > > > > option ROM loader. The result is that a couple instructions are > > > > > overwritten. Typically one or two tests fail and that's it... > > > > > > > > > > Move the code above the forbidden region, in real 90s style. > > > > > > > > > > Reported-by: Thomas Huth <[[thuth@redhat.com](mailto:thuth@redhat.com)](mailto:[thuth@redhat.com](mailto:thuth@redhat.com))> > > > > > Signed-off-by: Paolo Bonzini <[[pbonzini@redhat.com](mailto:pbonzini@redhat.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com))> > > > > > --- > > > > > x86/realmode.lds | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/x86/realmode.lds b/x86/realmode.lds > > > > > index 0ed3063b..e4782a98 100644 > > > > > --- a/x86/realmode.lds > > > > > +++ b/x86/realmode.lds > > > > > @@ -1,6 +1,6 @@ > > > > > SECTIONS > > > > > { > > > > > - . = 16K; > > > > > + . = 32K; > > > > > stext = .; > > > > > .text : { *(.init) *(.text) } > > > > > . = ALIGN(4K); > > > > > > > > > > > > > > > > Hi Paolo! > > > > > > > > FYI, the realmode kvm-unit-test now also fails with the recent version > > > > of GCC 16 for the i386 target: > > > > > > > > [[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)) > > > > > > > > It was working fine some weeks ago with GCC 15.1: > > > > > > > > [[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)) > > > > > > > > When I apply your patch, the problem seems to be gone again in this > > > > case, but since there were some other issues with this (with older > > > > versions of GCC, I think): > > > > > > > > [[https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)) > > > > > > > > ... there must be a better way to fix it? > > > > > > > > Could you please have a look? > > > > > > > > > > > > By the way, the intel_iommu test now also suddenly started failing (for the > > > x86_64 target), either due to update of GCC or due to the update from QEMU > > > v10.2 to 11.0 : > > > > > > [[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)) > > > > > > Two weeks ago, it was still working fine: > > > > > > [[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)) > > > > > > > > Looping in those who take care of qemu's VT-D now (Yi, Clément).. > > > > -- > > Peter Xu > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) 2026-05-05 6:37 ` Clément MATHIEU--DRIF @ 2026-05-05 7:36 ` Clément MATHIEU--DRIF 2026-05-05 9:27 ` Clément MATHIEU--DRIF 0 siblings, 1 reply; 20+ messages in thread From: Clément MATHIEU--DRIF @ 2026-05-05 7:36 UTC (permalink / raw) To: Peter Xu, Thomas Huth Cc: Paolo Bonzini, kvm@vger.kernel.org, Yi Liu, Michael S. Tsirkin Back with some answers: This is the incriminated hunk: ```diff --- <unnamed> +++ <unnamed> @@ -1,17 +1,16 @@ - 404395: 8b 80 98 00 00 00 mov 0x98(%eax),%eax + 40441d: 8b 43 38 mov 0x38(%ebx),%eax edu_reg_writeq(dev, EDU_REG_DMA_DST, to); edu_reg_writeq(dev, EDU_REG_DMA_COUNT, size); edu_reg_writel(dev, EDU_REG_DMA_CMD, cmd); /* Wait until DMA finished */ while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) - 40439b: a8 01 test $0x1,%al - 40439d: 74 10 je 4043af <edu_dma+0x121> - 40439f: f3 90 pause - 4043a1: 48 dec %eax - 4043a2: 8b 43 38 mov 0x38(%ebx),%eax - 4043a5: 8b 80 98 00 00 00 mov 0x98(%eax),%eax - 4043ab: a8 01 test $0x1,%al - 4043ad: 75 f0 jne 40439f <edu_dma+0x111> + 404420: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) + 404427: 74 0f je 404438 <edu_dma+0x11f> + 404429: f3 90 pause + 40442b: 48 dec %eax + 40442c: 8b 43 38 mov 0x38(%ebx),%eax + 40442f: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) + 404436: 75 f1 jne 404429 <edu_dma+0x110> cpu_relax(); } + is gcc 16 - is gcc 15 The instructions generated by gcc 16 always skip the following condition: ``` /* Wait until DMA finished */ while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) cpu_relax(); ``` As a consequence, the test performs the second dma operation too early and reads a wrong value. Regards, cmd On Tue, 2026-05-05 at 08:37 +0200, Clement Mathieu--Drif wrote: > I will try to investigate today, it seems that the host does not wait for the dma operation to complete before reading back. > > keep you posted > > cmd > > On Tue, 2026-05-05 at 07:49 +0200, Clement Mathieu--Drif wrote: > > > Hi, > > > > Indeed, it seems to start failing when switching to gcc 16.1. > > > > gcc 15.2.1 - Qemu 11 => pass > > gcc 16.1 - Qemu 11 => fail > > > > On Mon, 2026-05-04 at 11:45 -0400, Peter Xu wrote: > > > > > > > Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. > > > > > > > > > On Mon, May 04, 2026 at 10:07:25AM +0200, Thomas Huth wrote: > > > > > > > > > > > > > On 04/05/2026 09.58, Thomas Huth wrote: > > > > > > > > > > > > > > > > > On 04/06/2024 16.35, Paolo Bonzini wrote: > > > > > > > > > > > > > > > > > > > > > The bottom 32K of memory are generally reserved for use by the BIOS; > > > > > > for example, traditionally the boot loader is placed at 0x7C00 and > > > > > > the stack grows below that address. > > > > > > > > > > > > It turns out that with some versions of clang, realmode.flat has > > > > > > become big enough that it overlaps the stack used by the multiboot > > > > > > option ROM loader. The result is that a couple instructions are > > > > > > overwritten. Typically one or two tests fail and that's it... > > > > > > > > > > > > Move the code above the forbidden region, in real 90s style. > > > > > > > > > > > > Reported-by: Thomas Huth <[[[thuth@redhat.com](mailto:thuth@redhat.com)](mailto:[thuth@redhat.com](mailto:thuth@redhat.com))](mailto:[[thuth@redhat.com](mailto:thuth@redhat.com)](mailto:[thuth@redhat.com](mailto:thuth@redhat.com)))> > > > > > > Signed-off-by: Paolo Bonzini <[[[pbonzini@redhat.com](mailto:pbonzini@redhat.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com))](mailto:[[pbonzini@redhat.com](mailto:pbonzini@redhat.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com)))> > > > > > > --- > > > > > > x86/realmode.lds | 2 +- > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/x86/realmode.lds b/x86/realmode.lds > > > > > > index 0ed3063b..e4782a98 100644 > > > > > > --- a/x86/realmode.lds > > > > > > +++ b/x86/realmode.lds > > > > > > @@ -1,6 +1,6 @@ > > > > > > SECTIONS > > > > > > { > > > > > > - . = 16K; > > > > > > + . = 32K; > > > > > > stext = .; > > > > > > .text : { *(.init) *(.text) } > > > > > > . = ALIGN(4K); > > > > > > > > > > > > > > > > > > > > > > > > > Hi Paolo! > > > > > > > > > > FYI, the realmode kvm-unit-test now also fails with the recent version > > > > > of GCC 16 for the i386 target: > > > > > > > > > > [[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727))) > > > > > > > > > > It was working fine some weeks ago with GCC 15.1: > > > > > > > > > > [[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961))) > > > > > > > > > > When I apply your patch, the problem seems to be gone again in this > > > > > case, but since there were some other issues with this (with older > > > > > versions of GCC, I think): > > > > > > > > > > [[[https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/))](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/))) > > > > > > > > > > ... there must be a better way to fix it? > > > > > > > > > > Could you please have a look? > > > > > > > > > > > > > > > > > > > > By the way, the intel_iommu test now also suddenly started failing (for the > > > > x86_64 target), either due to update of GCC or due to the update from QEMU > > > > v10.2 to 11.0 : > > > > > > > > [[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728))) > > > > > > > > Two weeks ago, it was still working fine: > > > > > > > > [[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962))) > > > > > > > > > > > > > > > Looping in those who take care of qemu's VT-D now (Yi, Clément).. > > > > > > -- > > > Peter Xu > > > > > > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) 2026-05-05 7:36 ` Clément MATHIEU--DRIF @ 2026-05-05 9:27 ` Clément MATHIEU--DRIF 2026-05-05 9:45 ` intel_iommu unit test is also failing Thomas Huth 0 siblings, 1 reply; 20+ messages in thread From: Clément MATHIEU--DRIF @ 2026-05-05 9:27 UTC (permalink / raw) To: Peter Xu, Thomas Huth Cc: Paolo Bonzini, kvm@vger.kernel.org, Yi Liu, Michael S. Tsirkin I had a bit more time to hook into qemu to check the root cause. It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: ``` Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 1473 unsigned size = memop_size(op); (gdb) n 1474 MemTxResult r; (gdb) p size $1 = 1 (gdb) ``` cmd On Tue, 2026-05-05 at 09:36 +0200, Clement Mathieu--Drif wrote: > Back with some answers: > > This is the incriminated hunk: > > ```diff > --- <unnamed> > +++ <unnamed> > @@ -1,17 +1,16 @@ > - 404395: 8b 80 98 00 00 00 mov 0x98(%eax),%eax > + 40441d: 8b 43 38 mov 0x38(%ebx),%eax > edu_reg_writeq(dev, EDU_REG_DMA_DST, to); > edu_reg_writeq(dev, EDU_REG_DMA_COUNT, size); > edu_reg_writel(dev, EDU_REG_DMA_CMD, cmd); > > /* Wait until DMA finished */ > while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) > - 40439b: a8 01 test $0x1,%al > - 40439d: 74 10 je 4043af <edu_dma+0x121> > - 40439f: f3 90 pause > - 4043a1: 48 dec %eax > - 4043a2: 8b 43 38 mov 0x38(%ebx),%eax > - 4043a5: 8b 80 98 00 00 00 mov 0x98(%eax),%eax > - 4043ab: a8 01 test $0x1,%al > - 4043ad: 75 f0 jne 40439f <edu_dma+0x111> > + 404420: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) > + 404427: 74 0f je 404438 <edu_dma+0x11f> > + 404429: f3 90 pause > + 40442b: 48 dec %eax > + 40442c: 8b 43 38 mov 0x38(%ebx),%eax > + 40442f: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) > + 404436: 75 f1 jne 404429 <edu_dma+0x110> > cpu_relax(); > } > > + is gcc 16 > - is gcc 15 > > The instructions generated by gcc 16 always skip the following condition: > > ``` > /* Wait until DMA finished */ > while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) > cpu_relax(); > ``` > > As a consequence, the test performs the second dma operation too early and reads a wrong value. > > Regards, > cmd > > On Tue, 2026-05-05 at 08:37 +0200, Clement Mathieu--Drif wrote: > > > I will try to investigate today, it seems that the host does not wait for the dma operation to complete before reading back. > > > > keep you posted > > > > cmd > > > > On Tue, 2026-05-05 at 07:49 +0200, Clement Mathieu--Drif wrote: > > > > > > > Hi, > > > > > > Indeed, it seems to start failing when switching to gcc 16.1. > > > > > > gcc 15.2.1 - Qemu 11 => pass > > > gcc 16.1 - Qemu 11 => fail > > > > > > On Mon, 2026-05-04 at 11:45 -0400, Peter Xu wrote: > > > > > > > > > > > > > Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. > > > > > > > > > > > > On Mon, May 04, 2026 at 10:07:25AM +0200, Thomas Huth wrote: > > > > > > > > > > > > > > > > > > > > > On 04/05/2026 09.58, Thomas Huth wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On 04/06/2024 16.35, Paolo Bonzini wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The bottom 32K of memory are generally reserved for use by the BIOS; > > > > > > > for example, traditionally the boot loader is placed at 0x7C00 and > > > > > > > the stack grows below that address. > > > > > > > > > > > > > > It turns out that with some versions of clang, realmode.flat has > > > > > > > become big enough that it overlaps the stack used by the multiboot > > > > > > > option ROM loader. The result is that a couple instructions are > > > > > > > overwritten. Typically one or two tests fail and that's it... > > > > > > > > > > > > > > Move the code above the forbidden region, in real 90s style. > > > > > > > > > > > > > > Reported-by: Thomas Huth <[[[[thuth@redhat.com](mailto:thuth@redhat.com)](mailto:[thuth@redhat.com](mailto:thuth@redhat.com))](mailto:[[thuth@redhat.com](mailto:thuth@redhat.com)](mailto:[thuth@redhat.com](mailto:thuth@redhat.com)))](mailto:[[[thuth@redhat.com](mailto:thuth@redhat.com)](mailto:[thuth@redhat.com](mailto:thuth@redhat.com))](mailto:[[thuth@redhat.com](mailto:thuth@redhat.com)](mailto:[thuth@redhat.com](mailto:thuth@redhat.com))))> > > > > > > > Signed-off-by: Paolo Bonzini <[[[[pbonzini@redhat.com](mailto:pbonzini@redhat.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com))](mailto:[[pbonzini@redhat.com](mailto:pbonzini@redhat.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com)))](mailto:[[[pbonzini@redhat.com](mailto:pbonzini@redhat.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com))](mailto:[[pbonzini@redhat.com](mailto:pbonzini@redhat.com)](mailto:[pbonzini@redhat.com](mailto:pbonzini@redhat.com))))> > > > > > > > --- > > > > > > > x86/realmode.lds | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/x86/realmode.lds b/x86/realmode.lds > > > > > > > index 0ed3063b..e4782a98 100644 > > > > > > > --- a/x86/realmode.lds > > > > > > > +++ b/x86/realmode.lds > > > > > > > @@ -1,6 +1,6 @@ > > > > > > > SECTIONS > > > > > > > { > > > > > > > - . = 16K; > > > > > > > + . = 32K; > > > > > > > stext = .; > > > > > > > .text : { *(.init) *(.text) } > > > > > > > . = ALIGN(4K); > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Paolo! > > > > > > > > > > > > FYI, the realmode kvm-unit-test now also fails with the recent version > > > > > > of GCC 16 for the i386 target: > > > > > > > > > > > > [[[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195727)))) > > > > > > > > > > > > It was working fine some weeks ago with GCC 15.1: > > > > > > > > > > > > [[[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260961)))) > > > > > > > > > > > > When I apply your patch, the problem seems to be gone again in this > > > > > > case, but since there were some other issues with this (with older > > > > > > versions of GCC, I think): > > > > > > > > > > > > [[[[https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/))](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)))](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/))](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/](https://lore.kernel.org/kvm/49f8aadf-6e3f-4d2b-a32a-8ba941a3a2a1@redhat.com/)))) > > > > > > > > > > > > ... there must be a better way to fix it? > > > > > > > > > > > > Could you please have a look? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > By the way, the intel_iommu test now also suddenly started failing (for the > > > > > x86_64 target), either due to update of GCC or due to the update from QEMU > > > > > v10.2 to 11.0 : > > > > > > > > > > [[[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/14195195728)))) > > > > > > > > > > Two weeks ago, it was still working fine: > > > > > > > > > > [[[[https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962))](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962](https://gitlab.com/kvm-unit-tests/kvm-unit-tests/-/jobs/13977260962)))) > > > > > > > > > > > > > > > > > > > > > > > > Looping in those who take care of qemu's VT-D now (Yi, Clément).. > > > > > > > > -- > > > > Peter Xu > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 9:27 ` Clément MATHIEU--DRIF @ 2026-05-05 9:45 ` Thomas Huth 2026-05-05 9:53 ` Clément MATHIEU--DRIF 2026-05-05 10:23 ` Michael S. Tsirkin 0 siblings, 2 replies; 20+ messages in thread From: Thomas Huth @ 2026-05-05 9:45 UTC (permalink / raw) To: Clément MATHIEU--DRIF, Peter Xu Cc: Paolo Bonzini, kvm@vger.kernel.org, Yi Liu, Michael S. Tsirkin On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: > I had a bit more time to hook into qemu to check the root cause. > > It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: > > ``` > Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 > 1473 unsigned size = memop_size(op); > (gdb) n > 1474 MemTxResult r; > (gdb) p size > $1 = 1 > (gdb) > ``` Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough to see that we only want to test the lowest bit here, so it optimizes the code to access only one byte of memory instead of 4 bytes... which would be ok for normal memory, but not for an MMIO register :-/ Ugly work-around, to force GCC to read 32 bits: diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h --- a/lib/asm-generic/io.h +++ b/lib/asm-generic/io.h @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) #ifndef __raw_readl static inline u32 __raw_readl(const volatile void *addr) { - return *(const volatile u32 *)addr; + u32 val = *(const volatile u32 *)addr; + asm volatile ("\n" : : "r"(addr)); + return val; } #endif ... but I wonder whether this should rather be treated as a bug in GCC instead, since it should IMHO really not change the access size for a volatile memory access? Thomas > cmd > > On Tue, 2026-05-05 at 09:36 +0200, Clement Mathieu--Drif wrote: >> Back with some answers: >> >> This is the incriminated hunk: >> >> ```diff >> --- <unnamed> >> +++ <unnamed> >> @@ -1,17 +1,16 @@ >> - 404395: 8b 80 98 00 00 00 mov 0x98(%eax),%eax >> + 40441d: 8b 43 38 mov 0x38(%ebx),%eax >> edu_reg_writeq(dev, EDU_REG_DMA_DST, to); >> edu_reg_writeq(dev, EDU_REG_DMA_COUNT, size); >> edu_reg_writel(dev, EDU_REG_DMA_CMD, cmd); >> >> /* Wait until DMA finished */ >> while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) >> - 40439b: a8 01 test $0x1,%al >> - 40439d: 74 10 je 4043af <edu_dma+0x121> >> - 40439f: f3 90 pause >> - 4043a1: 48 dec %eax >> - 4043a2: 8b 43 38 mov 0x38(%ebx),%eax >> - 4043a5: 8b 80 98 00 00 00 mov 0x98(%eax),%eax >> - 4043ab: a8 01 test $0x1,%al >> - 4043ad: 75 f0 jne 40439f <edu_dma+0x111> >> + 404420: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) >> + 404427: 74 0f je 404438 <edu_dma+0x11f> >> + 404429: f3 90 pause >> + 40442b: 48 dec %eax >> + 40442c: 8b 43 38 mov 0x38(%ebx),%eax >> + 40442f: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) >> + 404436: 75 f1 jne 404429 <edu_dma+0x110> >> cpu_relax(); >> } >> >> + is gcc 16 >> - is gcc 15 >> >> The instructions generated by gcc 16 always skip the following condition: >> >> ``` >> /* Wait until DMA finished */ >> while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) >> cpu_relax(); >> ``` >> >> As a consequence, the test performs the second dma operation too early and reads a wrong value. >> >> Regards, >> cmd ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 9:45 ` intel_iommu unit test is also failing Thomas Huth @ 2026-05-05 9:53 ` Clément MATHIEU--DRIF 2026-05-05 10:15 ` Thomas Huth 2026-05-05 10:23 ` Michael S. Tsirkin 1 sibling, 1 reply; 20+ messages in thread From: Clément MATHIEU--DRIF @ 2026-05-05 9:53 UTC (permalink / raw) To: Thomas Huth, Peter Xu Cc: Paolo Bonzini, kvm@vger.kernel.org, Yi Liu, Michael S. Tsirkin On Tue, 2026-05-05 at 11:45 +0200, Thomas Huth wrote: > Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. > > > On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: > > > I had a bit more time to hook into qemu to check the root cause. > > > > It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: > > > > ``` > > Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 > > 1473 unsigned size = memop_size(op); > > (gdb) n > > 1474 MemTxResult r; > > (gdb) p size > > $1 = 1 > > (gdb) > > ``` > > > Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough > to see that we only want to test the lowest bit here, so it optimizes the > code to access only one byte of memory instead of 4 bytes... which would be > ok for normal memory, but not for an MMIO register :-/ > > Ugly work-around, to force GCC to read 32 bits: > > diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h > --- a/lib/asm-generic/io.h > +++ b/lib/asm-generic/io.h > @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) > #ifndef __raw_readl > static inline u32 __raw_readl(const volatile void *addr) > { > - return *(const volatile u32 *)addr; > + u32 val = *(const volatile u32 *)addr; > + asm volatile ("\n" : : "r"(addr)); > + return val; > } > #endif > > ... but I wonder whether this should rather be treated as a bug in GCC > instead, since it should IMHO really not change the access size for a > volatile memory access? Volatile is expected to make sure that the read side effect is visible. I don't know if the size of the access is in the scope of this constraint or not o.O > > Thomas > > > > > cmd > > > > On Tue, 2026-05-05 at 09:36 +0200, Clement Mathieu--Drif wrote: > > > > > Back with some answers: > > > > > > This is the incriminated hunk: > > > > > > ```diff > > > --- <unnamed> > > > +++ <unnamed> > > > @@ -1,17 +1,16 @@ > > > - 404395: 8b 80 98 00 00 00 mov 0x98(%eax),%eax > > > + 40441d: 8b 43 38 mov 0x38(%ebx),%eax > > > edu_reg_writeq(dev, EDU_REG_DMA_DST, to); > > > edu_reg_writeq(dev, EDU_REG_DMA_COUNT, size); > > > edu_reg_writel(dev, EDU_REG_DMA_CMD, cmd); > > > > > > /* Wait until DMA finished */ > > > while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) > > > - 40439b: a8 01 test $0x1,%al > > > - 40439d: 74 10 je 4043af <edu_dma+0x121> > > > - 40439f: f3 90 pause > > > - 4043a1: 48 dec %eax > > > - 4043a2: 8b 43 38 mov 0x38(%ebx),%eax > > > - 4043a5: 8b 80 98 00 00 00 mov 0x98(%eax),%eax > > > - 4043ab: a8 01 test $0x1,%al > > > - 4043ad: 75 f0 jne 40439f <edu_dma+0x111> > > > + 404420: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) > > > + 404427: 74 0f je 404438 <edu_dma+0x11f> > > > + 404429: f3 90 pause > > > + 40442b: 48 dec %eax > > > + 40442c: 8b 43 38 mov 0x38(%ebx),%eax > > > + 40442f: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) > > > + 404436: 75 f1 jne 404429 <edu_dma+0x110> > > > cpu_relax(); > > > } > > > > > > + is gcc 16 > > > - is gcc 15 > > > > > > The instructions generated by gcc 16 always skip the following condition: > > > > > > ``` > > > /* Wait until DMA finished */ > > > while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) > > > cpu_relax(); > > > ``` > > > > > > As a consequence, the test performs the second dma operation too early and reads a wrong value. > > > > > > Regards, > > > cmd > > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 9:53 ` Clément MATHIEU--DRIF @ 2026-05-05 10:15 ` Thomas Huth 0 siblings, 0 replies; 20+ messages in thread From: Thomas Huth @ 2026-05-05 10:15 UTC (permalink / raw) To: Clément MATHIEU--DRIF, Peter Xu Cc: Paolo Bonzini, kvm@vger.kernel.org, Yi Liu, Michael S. Tsirkin On 05/05/2026 11.53, Clément MATHIEU--DRIF wrote: > > > On Tue, 2026-05-05 at 11:45 +0200, Thomas Huth wrote: >> Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. >> >> >> On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: >> >>> I had a bit more time to hook into qemu to check the root cause. >>> >>> It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: >>> >>> ``` >>> Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 >>> 1473 unsigned size = memop_size(op); >>> (gdb) n >>> 1474 MemTxResult r; >>> (gdb) p size >>> $1 = 1 >>> (gdb) >>> ``` >> >> >> Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough >> to see that we only want to test the lowest bit here, so it optimizes the >> code to access only one byte of memory instead of 4 bytes... which would be >> ok for normal memory, but not for an MMIO register :-/ >> >> Ugly work-around, to force GCC to read 32 bits: >> >> diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h >> --- a/lib/asm-generic/io.h >> +++ b/lib/asm-generic/io.h >> @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) >> #ifndef __raw_readl >> static inline u32 __raw_readl(const volatile void *addr) >> { >> - return *(const volatile u32 *)addr; >> + u32 val = *(const volatile u32 *)addr; >> + asm volatile ("\n" : : "r"(addr)); >> + return val; >> } >> #endif >> >> ... but I wonder whether this should rather be treated as a bug in GCC >> instead, since it should IMHO really not change the access size for a >> volatile memory access? > > Volatile is expected to make sure that the read side effect is visible. > I don't know if the size of the access is in the scope of this constraint or not o.O Maybe we should simply adjust the read/write functions in the pci-edu.h code, WDYT: diff --git a/lib/pci-edu.h b/lib/pci-edu.h --- a/lib/pci-edu.h +++ b/lib/pci-edu.h @@ -59,24 +59,24 @@ struct pci_edu_dev { static inline uint64_t edu_reg_readq(struct pci_edu_dev *dev, int reg) { - return __raw_readq(edu_reg(dev, reg)); + return readq(edu_reg(dev, reg)); } static inline uint32_t edu_reg_readl(struct pci_edu_dev *dev, int reg) { - return __raw_readl(edu_reg(dev, reg)); + return readl(edu_reg(dev, reg)); } static inline void edu_reg_writeq(struct pci_edu_dev *dev, int reg, uint64_t val) { - __raw_writeq(val, edu_reg(dev, reg)); + writeq(val, edu_reg(dev, reg)); } static inline void edu_reg_writel(struct pci_edu_dev *dev, int reg, uint32_t val) { - __raw_writel(val, edu_reg(dev, reg)); + writel(val, edu_reg(dev, reg)); } bool edu_init(struct pci_edu_dev *dev); ... it might be good to use the non-raw functions here for ordered access anyway... Thomas ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 9:45 ` intel_iommu unit test is also failing Thomas Huth 2026-05-05 9:53 ` Clément MATHIEU--DRIF @ 2026-05-05 10:23 ` Michael S. Tsirkin 2026-05-05 10:34 ` Thomas Huth 1 sibling, 1 reply; 20+ messages in thread From: Michael S. Tsirkin @ 2026-05-05 10:23 UTC (permalink / raw) To: Thomas Huth Cc: Clément MATHIEU--DRIF, Peter Xu, Paolo Bonzini, kvm@vger.kernel.org, Yi Liu On Tue, May 05, 2026 at 11:45:17AM +0200, Thomas Huth wrote: > On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: > > I had a bit more time to hook into qemu to check the root cause. > > > > It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: > > > > ``` > > Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 > > 1473 unsigned size = memop_size(op); > > (gdb) n > > 1474 MemTxResult r; > > (gdb) p size > > $1 = 1 > > (gdb) > > ``` > > Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough > to see that we only want to test the lowest bit here, so it optimizes the > code to access only one byte of memory instead of 4 bytes... which would be > ok for normal memory, but not for an MMIO register :-/ > > Ugly work-around, to force GCC to read 32 bits: > > diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h > --- a/lib/asm-generic/io.h > +++ b/lib/asm-generic/io.h > @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) > #ifndef __raw_readl > static inline u32 __raw_readl(const volatile void *addr) > { > - return *(const volatile u32 *)addr; > + u32 val = *(const volatile u32 *)addr; > + asm volatile ("\n" : : "r"(addr)); > + return val; > } > #endif > > ... but I wonder whether this should rather be treated as a bug in GCC > instead, since it should IMHO really not change the access size for a > volatile memory access? > > Thomas Wouldn't this break linux generally? #ifndef __READ_ONCE #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) #endif > > > cmd > > > > On Tue, 2026-05-05 at 09:36 +0200, Clement Mathieu--Drif wrote: > > > Back with some answers: > > > > > > This is the incriminated hunk: > > > > > > ```diff > > > --- <unnamed> > > > +++ <unnamed> > > > @@ -1,17 +1,16 @@ > > > - 404395: 8b 80 98 00 00 00 mov 0x98(%eax),%eax > > > + 40441d: 8b 43 38 mov 0x38(%ebx),%eax > > > edu_reg_writeq(dev, EDU_REG_DMA_DST, to); > > > edu_reg_writeq(dev, EDU_REG_DMA_COUNT, size); > > > edu_reg_writel(dev, EDU_REG_DMA_CMD, cmd); > > > > > > /* Wait until DMA finished */ > > > while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) > > > - 40439b: a8 01 test $0x1,%al > > > - 40439d: 74 10 je 4043af <edu_dma+0x121> > > > - 40439f: f3 90 pause > > > - 4043a1: 48 dec %eax > > > - 4043a2: 8b 43 38 mov 0x38(%ebx),%eax > > > - 4043a5: 8b 80 98 00 00 00 mov 0x98(%eax),%eax > > > - 4043ab: a8 01 test $0x1,%al > > > - 4043ad: 75 f0 jne 40439f <edu_dma+0x111> > > > + 404420: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) > > > + 404427: 74 0f je 404438 <edu_dma+0x11f> > > > + 404429: f3 90 pause > > > + 40442b: 48 dec %eax > > > + 40442c: 8b 43 38 mov 0x38(%ebx),%eax > > > + 40442f: f6 80 98 00 00 00 01 testb $0x1,0x98(%eax) > > > + 404436: 75 f1 jne 404429 <edu_dma+0x110> > > > cpu_relax(); > > > } > > > > > > + is gcc 16 > > > - is gcc 15 > > > > > > The instructions generated by gcc 16 always skip the following condition: > > > > > > ``` > > > /* Wait until DMA finished */ > > > while (edu_reg_readl(dev, EDU_REG_DMA_CMD) & EDU_CMD_DMA_START) > > > cpu_relax(); > > > ``` > > > > > > As a consequence, the test performs the second dma operation too early and reads a wrong value. > > > > > > Regards, > > > cmd ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 10:23 ` Michael S. Tsirkin @ 2026-05-05 10:34 ` Thomas Huth 2026-05-05 10:53 ` Michael S. Tsirkin 0 siblings, 1 reply; 20+ messages in thread From: Thomas Huth @ 2026-05-05 10:34 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Clément MATHIEU--DRIF, Peter Xu, Paolo Bonzini, kvm@vger.kernel.org, Yi Liu On 05/05/2026 12.23, Michael S. Tsirkin wrote: > On Tue, May 05, 2026 at 11:45:17AM +0200, Thomas Huth wrote: >> On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: >>> I had a bit more time to hook into qemu to check the root cause. >>> >>> It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: >>> >>> ``` >>> Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 >>> 1473 unsigned size = memop_size(op); >>> (gdb) n >>> 1474 MemTxResult r; >>> (gdb) p size >>> $1 = 1 >>> (gdb) >>> ``` >> >> Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough >> to see that we only want to test the lowest bit here, so it optimizes the >> code to access only one byte of memory instead of 4 bytes... which would be >> ok for normal memory, but not for an MMIO register :-/ >> >> Ugly work-around, to force GCC to read 32 bits: >> >> diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h >> --- a/lib/asm-generic/io.h >> +++ b/lib/asm-generic/io.h >> @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) >> #ifndef __raw_readl >> static inline u32 __raw_readl(const volatile void *addr) >> { >> - return *(const volatile u32 *)addr; >> + u32 val = *(const volatile u32 *)addr; >> + asm volatile ("\n" : : "r"(addr)); >> + return val; >> } >> #endif >> >> ... but I wonder whether this should rather be treated as a bug in GCC >> instead, since it should IMHO really not change the access size for a >> volatile memory access? >> >> Thomas > > Wouldn't this break linux generally? > > #ifndef __READ_ONCE > #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) > #endif I asked myself the very same question, but after googling for "GCC 16 linux kernel" issues, I did not find anything related... there is likely something specific to kvm-unit-tests in here... Thomas ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 10:34 ` Thomas Huth @ 2026-05-05 10:53 ` Michael S. Tsirkin 2026-05-05 11:38 ` Thomas Huth 2026-05-05 11:39 ` Clément MATHIEU--DRIF 0 siblings, 2 replies; 20+ messages in thread From: Michael S. Tsirkin @ 2026-05-05 10:53 UTC (permalink / raw) To: Thomas Huth Cc: Clément MATHIEU--DRIF, Peter Xu, Paolo Bonzini, kvm@vger.kernel.org, Yi Liu On Tue, May 05, 2026 at 12:34:41PM +0200, Thomas Huth wrote: > On 05/05/2026 12.23, Michael S. Tsirkin wrote: > > On Tue, May 05, 2026 at 11:45:17AM +0200, Thomas Huth wrote: > > > On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: > > > > I had a bit more time to hook into qemu to check the root cause. > > > > > > > > It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: > > > > > > > > ``` > > > > Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 > > > > 1473 unsigned size = memop_size(op); > > > > (gdb) n > > > > 1474 MemTxResult r; > > > > (gdb) p size > > > > $1 = 1 > > > > (gdb) > > > > ``` > > > > > > Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough > > > to see that we only want to test the lowest bit here, so it optimizes the > > > code to access only one byte of memory instead of 4 bytes... which would be > > > ok for normal memory, but not for an MMIO register :-/ > > > > > > Ugly work-around, to force GCC to read 32 bits: > > > > > > diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h > > > --- a/lib/asm-generic/io.h > > > +++ b/lib/asm-generic/io.h > > > @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) > > > #ifndef __raw_readl > > > static inline u32 __raw_readl(const volatile void *addr) > > > { > > > - return *(const volatile u32 *)addr; > > > + u32 val = *(const volatile u32 *)addr; > > > + asm volatile ("\n" : : "r"(addr)); > > > + return val; > > > } > > > #endif > > > > > > ... but I wonder whether this should rather be treated as a bug in GCC > > > instead, since it should IMHO really not change the access size for a > > > volatile memory access? > > > > > > Thomas > > > > Wouldn't this break linux generally? > > > > #ifndef __READ_ONCE > > #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) > > #endif > > I asked myself the very same question, but after googling for "GCC 16 linux > kernel" issues, I did not find anything related... there is likely something > specific to kvm-unit-tests in here... > > Thomas This seems to be pertinent: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html -ffuse-ops-with-volatile-access Allow limited optimization of operations with volatile memory access when doing so does not change the semantics outlined in See When is a Volatile Object Accessed?. The default is -ffuse-ops-with-volatile-access implemented here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122343 Try disabling? -fno-fuse-ops-with-volatile-access -- MST ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 10:53 ` Michael S. Tsirkin @ 2026-05-05 11:38 ` Thomas Huth 2026-05-05 12:33 ` Michael S. Tsirkin 2026-05-05 11:39 ` Clément MATHIEU--DRIF 1 sibling, 1 reply; 20+ messages in thread From: Thomas Huth @ 2026-05-05 11:38 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Clément MATHIEU--DRIF, Peter Xu, Paolo Bonzini, kvm@vger.kernel.org, Yi Liu On 05/05/2026 12.53, Michael S. Tsirkin wrote: > On Tue, May 05, 2026 at 12:34:41PM +0200, Thomas Huth wrote: >> On 05/05/2026 12.23, Michael S. Tsirkin wrote: >>> On Tue, May 05, 2026 at 11:45:17AM +0200, Thomas Huth wrote: >>>> On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: >>>>> I had a bit more time to hook into qemu to check the root cause. >>>>> >>>>> It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: >>>>> >>>>> ``` >>>>> Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 >>>>> 1473 unsigned size = memop_size(op); >>>>> (gdb) n >>>>> 1474 MemTxResult r; >>>>> (gdb) p size >>>>> $1 = 1 >>>>> (gdb) >>>>> ``` >>>> >>>> Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough >>>> to see that we only want to test the lowest bit here, so it optimizes the >>>> code to access only one byte of memory instead of 4 bytes... which would be >>>> ok for normal memory, but not for an MMIO register :-/ >>>> >>>> Ugly work-around, to force GCC to read 32 bits: >>>> >>>> diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h >>>> --- a/lib/asm-generic/io.h >>>> +++ b/lib/asm-generic/io.h >>>> @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) >>>> #ifndef __raw_readl >>>> static inline u32 __raw_readl(const volatile void *addr) >>>> { >>>> - return *(const volatile u32 *)addr; >>>> + u32 val = *(const volatile u32 *)addr; >>>> + asm volatile ("\n" : : "r"(addr)); >>>> + return val; >>>> } >>>> #endif >>>> >>>> ... but I wonder whether this should rather be treated as a bug in GCC >>>> instead, since it should IMHO really not change the access size for a >>>> volatile memory access? >>>> >>>> Thomas >>> >>> Wouldn't this break linux generally? >>> >>> #ifndef __READ_ONCE >>> #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) >>> #endif >> >> I asked myself the very same question, but after googling for "GCC 16 linux >> kernel" issues, I did not find anything related... there is likely something >> specific to kvm-unit-tests in here... >> >> Thomas > > > This seems to be pertinent: > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > -ffuse-ops-with-volatile-access > Allow limited optimization of operations with volatile memory access when doing so does not change the semantics outlined in See When is a Volatile Object Accessed?. > > The default is -ffuse-ops-with-volatile-access > > implemented here: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122343 > > Try disabling? -fno-fuse-ops-with-volatile-access Thanks, this seems to fix the issue, indeed! Would you like to send a patch for it? Thomas ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 11:38 ` Thomas Huth @ 2026-05-05 12:33 ` Michael S. Tsirkin 2026-05-05 17:08 ` Thomas Huth 0 siblings, 1 reply; 20+ messages in thread From: Michael S. Tsirkin @ 2026-05-05 12:33 UTC (permalink / raw) To: Thomas Huth Cc: Clément MATHIEU--DRIF, Peter Xu, Paolo Bonzini, kvm@vger.kernel.org, Yi Liu On Tue, May 05, 2026 at 01:38:26PM +0200, Thomas Huth wrote: > On 05/05/2026 12.53, Michael S. Tsirkin wrote: > > On Tue, May 05, 2026 at 12:34:41PM +0200, Thomas Huth wrote: > > > On 05/05/2026 12.23, Michael S. Tsirkin wrote: > > > > On Tue, May 05, 2026 at 11:45:17AM +0200, Thomas Huth wrote: > > > > > On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: > > > > > > I had a bit more time to hook into qemu to check the root cause. > > > > > > > > > > > > It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: > > > > > > > > > > > > ``` > > > > > > Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 > > > > > > 1473 unsigned size = memop_size(op); > > > > > > (gdb) n > > > > > > 1474 MemTxResult r; > > > > > > (gdb) p size > > > > > > $1 = 1 > > > > > > (gdb) > > > > > > ``` > > > > > > > > > > Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough > > > > > to see that we only want to test the lowest bit here, so it optimizes the > > > > > code to access only one byte of memory instead of 4 bytes... which would be > > > > > ok for normal memory, but not for an MMIO register :-/ > > > > > > > > > > Ugly work-around, to force GCC to read 32 bits: > > > > > > > > > > diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h > > > > > --- a/lib/asm-generic/io.h > > > > > +++ b/lib/asm-generic/io.h > > > > > @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) > > > > > #ifndef __raw_readl > > > > > static inline u32 __raw_readl(const volatile void *addr) > > > > > { > > > > > - return *(const volatile u32 *)addr; > > > > > + u32 val = *(const volatile u32 *)addr; > > > > > + asm volatile ("\n" : : "r"(addr)); > > > > > + return val; > > > > > } > > > > > #endif > > > > > > > > > > ... but I wonder whether this should rather be treated as a bug in GCC > > > > > instead, since it should IMHO really not change the access size for a > > > > > volatile memory access? > > > > > > > > > > Thomas > > > > > > > > Wouldn't this break linux generally? > > > > > > > > #ifndef __READ_ONCE > > > > #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) > > > > #endif > > > > > > I asked myself the very same question, but after googling for "GCC 16 linux > > > kernel" issues, I did not find anything related... there is likely something > > > specific to kvm-unit-tests in here... > > > > > > Thomas > > > > > > This seems to be pertinent: > > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html > > > > -ffuse-ops-with-volatile-access > > Allow limited optimization of operations with volatile memory access when doing so does not change the semantics outlined in See When is a Volatile Object Accessed?. > > > > The default is -ffuse-ops-with-volatile-access > > > > implemented here: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122343 > > > > Try disabling? -fno-fuse-ops-with-volatile-access > > Thanks, this seems to fix the issue, indeed! > > Would you like to send a patch for it? > > Thomas So then it's this bug apparently: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125180 will likely be in 16.2? Maybe just wait? -- MST ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 12:33 ` Michael S. Tsirkin @ 2026-05-05 17:08 ` Thomas Huth 0 siblings, 0 replies; 20+ messages in thread From: Thomas Huth @ 2026-05-05 17:08 UTC (permalink / raw) To: Michael S. Tsirkin Cc: Clément MATHIEU--DRIF, Peter Xu, Paolo Bonzini, kvm@vger.kernel.org, Yi Liu On 05/05/2026 14.33, Michael S. Tsirkin wrote: > On Tue, May 05, 2026 at 01:38:26PM +0200, Thomas Huth wrote: >> On 05/05/2026 12.53, Michael S. Tsirkin wrote: >>> On Tue, May 05, 2026 at 12:34:41PM +0200, Thomas Huth wrote: >>>> On 05/05/2026 12.23, Michael S. Tsirkin wrote: >>>>> On Tue, May 05, 2026 at 11:45:17AM +0200, Thomas Huth wrote: >>>>>> On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: >>>>>>> I had a bit more time to hook into qemu to check the root cause. >>>>>>> >>>>>>> It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: >>>>>>> >>>>>>> ``` >>>>>>> Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 >>>>>>> 1473 unsigned size = memop_size(op); >>>>>>> (gdb) n >>>>>>> 1474 MemTxResult r; >>>>>>> (gdb) p size >>>>>>> $1 = 1 >>>>>>> (gdb) >>>>>>> ``` >>>>>> >>>>>> Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough >>>>>> to see that we only want to test the lowest bit here, so it optimizes the >>>>>> code to access only one byte of memory instead of 4 bytes... which would be >>>>>> ok for normal memory, but not for an MMIO register :-/ >>>>>> >>>>>> Ugly work-around, to force GCC to read 32 bits: >>>>>> >>>>>> diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h >>>>>> --- a/lib/asm-generic/io.h >>>>>> +++ b/lib/asm-generic/io.h >>>>>> @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) >>>>>> #ifndef __raw_readl >>>>>> static inline u32 __raw_readl(const volatile void *addr) >>>>>> { >>>>>> - return *(const volatile u32 *)addr; >>>>>> + u32 val = *(const volatile u32 *)addr; >>>>>> + asm volatile ("\n" : : "r"(addr)); >>>>>> + return val; >>>>>> } >>>>>> #endif >>>>>> >>>>>> ... but I wonder whether this should rather be treated as a bug in GCC >>>>>> instead, since it should IMHO really not change the access size for a >>>>>> volatile memory access? >>>>>> >>>>>> Thomas >>>>> >>>>> Wouldn't this break linux generally? >>>>> >>>>> #ifndef __READ_ONCE >>>>> #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) >>>>> #endif >>>> >>>> I asked myself the very same question, but after googling for "GCC 16 linux >>>> kernel" issues, I did not find anything related... there is likely something >>>> specific to kvm-unit-tests in here... >>>> >>>> Thomas >>> >>> >>> This seems to be pertinent: >>> https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html >>> >>> -ffuse-ops-with-volatile-access >>> Allow limited optimization of operations with volatile memory access when doing so does not change the semantics outlined in See When is a Volatile Object Accessed?. >>> >>> The default is -ffuse-ops-with-volatile-access >>> >>> implemented here: >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122343 >>> >>> Try disabling? -fno-fuse-ops-with-volatile-access >> >> Thanks, this seems to fix the issue, indeed! >> >> Would you like to send a patch for it? > > So then it's this bug apparently: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125180 Ah, thanks, that looks like the bug, indeed! > will likely be in 16.2? > > Maybe just wait? I guess we could drop the failing test from the CI for the time being... Thomas ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: intel_iommu unit test is also failing 2026-05-05 10:53 ` Michael S. Tsirkin 2026-05-05 11:38 ` Thomas Huth @ 2026-05-05 11:39 ` Clément MATHIEU--DRIF 1 sibling, 0 replies; 20+ messages in thread From: Clément MATHIEU--DRIF @ 2026-05-05 11:39 UTC (permalink / raw) To: Michael S. Tsirkin, Thomas Huth Cc: Peter Xu, Paolo Bonzini, kvm@vger.kernel.org, Yi Liu On Tue, 2026-05-05 at 06:53 -0400, Michael S. Tsirkin wrote: > Caution: External email. Do not open attachments or click links, unless this email comes from a known sender and you know the content is safe. > > > On Tue, May 05, 2026 at 12:34:41PM +0200, Thomas Huth wrote: > > > On 05/05/2026 12.23, Michael S. Tsirkin wrote: > > > > > On Tue, May 05, 2026 at 11:45:17AM +0200, Thomas Huth wrote: > > > > > > > On 05/05/2026 11.27, Clément MATHIEU--DRIF wrote: > > > > > > > > > I had a bit more time to hook into qemu to check the root cause. > > > > > > > > > > It seems that testb issues a single byte read (out of the valid size range), as we can see on the following breakpoint: > > > > > > > > > > ``` > > > > > Thread 6 "CPU 0/TCG" hit Breakpoint 2, memory_region_dispatch_read (mr=0x55d72883cb30, addr=152, pval=0x7f62d25f4590, op=MO_BSWAP, attrs=...) at ../system/memory.c:1473 > > > > > 1473 unsigned size = memop_size(op); > > > > > (gdb) n > > > > > 1474 MemTxResult r; > > > > > (gdb) p size > > > > > $1 = 1 > > > > > (gdb) > > > > > ``` > > > > > > > > > > > > Ouch! That's an excellent finding, Clément ... so GCC 16 is "smart" enough > > > > to see that we only want to test the lowest bit here, so it optimizes the > > > > code to access only one byte of memory instead of 4 bytes... which would be > > > > ok for normal memory, but not for an MMIO register :-/ > > > > > > > > Ugly work-around, to force GCC to read 32 bits: > > > > > > > > diff --git a/lib/asm-generic/io.h b/lib/asm-generic/io.h > > > > --- a/lib/asm-generic/io.h > > > > +++ b/lib/asm-generic/io.h > > > > @@ -38,7 +38,9 @@ static inline u16 __raw_readw(const volatile void *addr) > > > > #ifndef __raw_readl > > > > static inline u32 __raw_readl(const volatile void *addr) > > > > { > > > > - return *(const volatile u32 *)addr; > > > > + u32 val = *(const volatile u32 *)addr; > > > > + asm volatile ("\n" : : "r"(addr)); > > > > + return val; > > > > } > > > > #endif > > > > > > > > ... but I wonder whether this should rather be treated as a bug in GCC > > > > instead, since it should IMHO really not change the access size for a > > > > volatile memory access? > > > > > > > > Thomas > > > > > > > > > Wouldn't this break linux generally? > > > > > > #ifndef __READ_ONCE > > > #define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x)) > > > #endif > > > > > > I asked myself the very same question, but after googling for "GCC 16 linux > > kernel" issues, I did not find anything related... there is likely something > > specific to kvm-unit-tests in here... > > > > Thomas > > > > This seems to be pertinent: > [https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html](https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html) > > -ffuse-ops-with-volatile-access > Allow limited optimization of operations with volatile memory access when doing so does not change the semantics outlined in See When is a Volatile Object Accessed?. > > The default is -ffuse-ops-with-volatile-access > > implemented here: > [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122343](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122343) > > > Try disabling? -fno-fuse-ops-with-volatile-access Good guess Michael, the test suite passes with this option set. cmd > > > -- > MST > ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2026-05-05 17:08 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-06-04 14:35 [PATCH kvm-unit-tests] realmode: load above stack Paolo Bonzini 2024-06-04 14:40 ` Thomas Huth 2024-06-04 14:50 ` Paolo Bonzini 2026-05-04 7:58 ` Thomas Huth 2026-05-04 8:07 ` intel_iommu unit test is also failing (was: Re: [PATCH kvm-unit-tests] realmode: load above stack) Thomas Huth 2026-05-04 15:45 ` Peter Xu 2026-05-05 5:49 ` Clément MATHIEU--DRIF 2026-05-05 6:37 ` Clément MATHIEU--DRIF 2026-05-05 7:36 ` Clément MATHIEU--DRIF 2026-05-05 9:27 ` Clément MATHIEU--DRIF 2026-05-05 9:45 ` intel_iommu unit test is also failing Thomas Huth 2026-05-05 9:53 ` Clément MATHIEU--DRIF 2026-05-05 10:15 ` Thomas Huth 2026-05-05 10:23 ` Michael S. Tsirkin 2026-05-05 10:34 ` Thomas Huth 2026-05-05 10:53 ` Michael S. Tsirkin 2026-05-05 11:38 ` Thomas Huth 2026-05-05 12:33 ` Michael S. Tsirkin 2026-05-05 17:08 ` Thomas Huth 2026-05-05 11:39 ` Clément MATHIEU--DRIF
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.