Re: [PULL 17/20] target/arm: Do memory type alignment check when translation disabled

2024-05-27 Thread Bernhard Beschow



Am 27. Mai 2024 16:20:44 UTC schrieb Richard Henderson 
:
>On 5/27/24 08:29, Bernhard Beschow wrote:
>> I think the kernel's output indicates that the MMU is active:
>> 
>>[7e849b05] *pgd=2c552831, *pte=109eb34f, *ppte=109eb83f
>> 
>> AFAIU, the value in brackets is a virtual address while the pte's are 
>> physical ones. Furthermore, the `info mtree` QMP command tells that the 
>> physical addresses are RAM addresses:
>> 
>>1000-2fff (prio 0, ram): sabrelite.ram
>> 
>> So I think we can conclude this to be "normal memory" to speak in ARM terms.
>
>Normal and Device are attributes on the page table entry.
>See section G5.7 Memory region attributes in the Arm ARM.
>
>But it's unlikely that the Linux kernel has messed this up, even back in 4.x 
>days.
>
>If you want to make any progress, you'll have to share a test case.

It's a proprietary guest, so I need to strip it down first. This may take some 
time. Thanks for yor feedbak so far!

Best regards,
Bernhard
>
>
>r~



Re: [PULL 17/20] target/arm: Do memory type alignment check when translation disabled

2024-05-27 Thread Bernhard Beschow



Am 27. Mai 2024 10:58:54 UTC schrieb Peter Maydell :
>On Mon, 27 May 2024 at 03:36, Richard Henderson
> wrote:
>>
>> On 5/25/24 13:50, Bernhard Beschow wrote:
>> >
>> >
>> > Am 25. Mai 2024 13:41:54 UTC schrieb Bernhard Beschow :
>> >>
>> >>
>> >> Am 5. März 2024 13:52:34 UTC schrieb Peter Maydell 
>> >> :
>> >>> From: Richard Henderson 
>> >>>
>> >>> If translation is disabled, the default memory type is Device, which
>> >>> requires alignment checking.  This is more optimally done early via
>> >>> the MemOp given to the TCG memory operation.
>> >>>
>> >>> Reviewed-by: Philippe Mathieu-Daudé 
>> >>> Reported-by: Idan Horowitz 
>> >>> Signed-off-by: Richard Henderson 
>> >>> Message-id: 20240301204110.656742-6-richard.hender...@linaro.org
>> >>> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204
>> >>> Signed-off-by: Richard Henderson 
>> >>> Signed-off-by: Peter Maydell 
>> >>
>> >> Hi,
>> >>
>> >> This change causes an old 4.14.40 Linux kernel to panic on boot using the 
>> >> sabrelite machine:
>> >>
>> >> [snip]
>> >> Alignment trap: init (1) PC=0x76f1e3d4 Instr=0x14913004 
>> >> Address=0x76f34f3e FSR 0x001
>> >> Alignment trap: init (1) PC=0x76f1e3d8 Instr=0x148c3004 
>> >> Address=0x7e8492bd FSR 0x801
>> >> Alignment trap: init (1) PC=0x76f0dab0 Instr=0x6823 Address=0x7e849fbb 
>> >> FSR 0x001
>> >> Alignment trap: init (1) PC=0x76f0dab2 Instr=0x6864 Address=0x7e849fbf 
>> >> FSR 0x001
>> >> scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK2.5+ PQ: 0 
>> >> ANSI: 5
>> >> fsl-asoc-card sound: ASoC: CODEC DAI sgtl5000 not registered
>> >> imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
>> >> imx-sgtl5000 sound: snd_soc_register_card failed (-517)
>> >> Alignment trap: init (1) PC=0x76eac95a Instr=0xf8dd5015 
>> >> Address=0x7e849b05 FSR 0x001
>> >> Alignment trap: not handling instruction f8dd5015 at [<76eac95a>]
>> >> Unhandled fault: alignment exception (0x001) at 0x7e849b05
>> >> pgd = 9c59c000
>> >> [7e849b05] *pgd=2c552831, *pte=109eb34f, *ppte=109eb83f
>> >> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007
>> >>
>> >> ---[ end Kernel panic - not syncing: Attempted to kill init! 
>> >> exitcode=0x0007
>> >>
>> >> As you can see, some alignment exceptions are handled by the kernel, the 
>> >> last one isn't. I added some additional printk()'s and traced it down to 
>> >> this location in the kernel: 
>> >> <https://github.com/torvalds/linux/blob/v4.14/arch/arm/mm/alignment.c#L762>
>> >>  which claims that ARMv6++ CPUs can handle up to word-sized unaligned 
>> >> accesses, thus no fixup is needed.
>> >>
>> >> I hope that this will be sufficient for a fix. Let me know if you need 
>> >> any additional information.
>> >
>> > I'm performing a direct kernel boot. On real hardware, a bootloader is 
>> > involved which probably enables unaligned access. This may explain why it 
>> > works there but not in QEMU any longer.
>> >
>> > To fix direct kernel boot, it seems as if the "built-in bootloader" would 
>> > need to be adapted/extended [1]. Any ideas?
>>
>> I strongly suspect a kernel bug.  Either mmu disabled or attempting 
>> unaligned access on
>> pages mapped as Device instead of Normal.
>
>The MMU surely must be enabled by this point in guest boot.
>This change doesn't affect whether we do alignment checks based
>on SCTLR.A being set, so it's not a simple "the bootloader was
>supposed to clear that and it didn't" (besides, A=0 means no
>checks, so that's the default anyway). So the failure is kind
>of weird.

I think the kernel's output indicates that the MMU is active:

  [7e849b05] *pgd=2c552831, *pte=109eb34f, *ppte=109eb83f

AFAIU, the value in brackets is a virtual address while the pte's are physical 
ones. Furthermore, the `info mtree` QMP command tells that the physical 
addresses are RAM addresses:

  1000-2fff (prio 0, ram): sabrelite.ram

So I think we can conclude this to be "normal memory" to speak in ARM terms.

Regarding the Linux kernel, it seems to me that it expects the unaligned 
accesses (up to word size) to be resolved by the hardware. On ARMv7 it can 
assume this, because the SCTLR.U bit is always set to 1 [1]. It then seems to 
only deal with cases which the hardware can't handle. In the case above, the 
unhandled instruction is (output from execlog plugin):

  0, 0x76ecc95a, 0x5015f8dd, "ldr.w r5, [sp, #0x15]"

Note that the correct order of the machine code is 
0xf8dd5015. This is not a pattern handled by the kernel, presumably because it 
expects it to be handled in hardware, hence the "not handling instruction xy" 
output. 

I have the impression that real hardware only traps when the hardware can't 
handle the unaligned access, and only when the SCTLR.A bit is set.

I'm not an ARM expert, so take this with a grain of salt.

Best regards,
Bernhard

[1] 
https://developer.arm.com/documentation/ddi0406/cb/Appendixes/ARMv6-Differences/Application-level-memory-support/Alignment


>
>-- PMM



Re: [PULL 17/20] target/arm: Do memory type alignment check when translation disabled

2024-05-25 Thread Bernhard Beschow



Am 25. Mai 2024 13:41:54 UTC schrieb Bernhard Beschow :
>
>
>Am 5. März 2024 13:52:34 UTC schrieb Peter Maydell :
>>From: Richard Henderson 
>>
>>If translation is disabled, the default memory type is Device, which
>>requires alignment checking.  This is more optimally done early via
>>the MemOp given to the TCG memory operation.
>>
>>Reviewed-by: Philippe Mathieu-Daudé 
>>Reported-by: Idan Horowitz 
>>Signed-off-by: Richard Henderson 
>>Message-id: 20240301204110.656742-6-richard.hender...@linaro.org
>>Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204
>>Signed-off-by: Richard Henderson 
>>Signed-off-by: Peter Maydell 
>
>Hi,
>
>This change causes an old 4.14.40 Linux kernel to panic on boot using the 
>sabrelite machine:
>
>[snip]
>Alignment trap: init (1) PC=0x76f1e3d4 Instr=0x14913004 Address=0x76f34f3e FSR 
>0x001
>Alignment trap: init (1) PC=0x76f1e3d8 Instr=0x148c3004 Address=0x7e8492bd FSR 
>0x801
>Alignment trap: init (1) PC=0x76f0dab0 Instr=0x6823 Address=0x7e849fbb FSR 
>0x001
>Alignment trap: init (1) PC=0x76f0dab2 Instr=0x6864 Address=0x7e849fbf FSR 
>0x001
>scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK2.5+ PQ: 0 ANSI: 5
>fsl-asoc-card sound: ASoC: CODEC DAI sgtl5000 not registered
>imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
>imx-sgtl5000 sound: snd_soc_register_card failed (-517)
>Alignment trap: init (1) PC=0x76eac95a Instr=0xf8dd5015 Address=0x7e849b05 FSR 
>0x001
>Alignment trap: not handling instruction f8dd5015 at [<76eac95a>]
>Unhandled fault: alignment exception (0x001) at 0x7e849b05
>pgd = 9c59c000
>[7e849b05] *pgd=2c552831, *pte=109eb34f, *ppte=109eb83f
>Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007
>
>---[ end Kernel panic - not syncing: Attempted to kill init! 
>exitcode=0x0007
>
>As you can see, some alignment exceptions are handled by the kernel, the last 
>one isn't. I added some additional printk()'s and traced it down to this 
>location in the kernel: 
><https://github.com/torvalds/linux/blob/v4.14/arch/arm/mm/alignment.c#L762> 
>which claims that ARMv6++ CPUs can handle up to word-sized unaligned accesses, 
>thus no fixup is needed.
>
>I hope that this will be sufficient for a fix. Let me know if you need any 
>additional information.

I'm performing a direct kernel boot. On real hardware, a bootloader is involved 
which probably enables unaligned access. This may explain why it works there 
but not in QEMU any longer.

To fix direct kernel boot, it seems as if the "built-in bootloader" would need 
to be adapted/extended [1]. Any ideas?

Best regards,
Bernhard

 [1] 
https://stackoverflow.com/questions/68949890/how-does-qemu-emulate-a-kernel-without-a-bootloader

>
>Best regards,
>Bernhard
>
>>---
>> target/arm/tcg/hflags.c | 34 --
>> 1 file changed, 32 insertions(+), 2 deletions(-)
>>
>>diff --git a/target/arm/tcg/hflags.c b/target/arm/tcg/hflags.c
>>index 8e5d35d9227..5da1b0fc1d4 100644
>>--- a/target/arm/tcg/hflags.c
>>+++ b/target/arm/tcg/hflags.c
>>@@ -26,6 +26,35 @@ static inline bool fgt_svc(CPUARMState *env, int el)
>> FIELD_EX64(env->cp15.fgt_exec[FGTREG_HFGITR], HFGITR_EL2, SVC_EL1);
>> }
>> 
>>+/* Return true if memory alignment should be enforced. */
>>+static bool aprofile_require_alignment(CPUARMState *env, int el, uint64_t 
>>sctlr)
>>+{
>>+#ifdef CONFIG_USER_ONLY
>>+return false;
>>+#else
>>+/* Check the alignment enable bit. */
>>+if (sctlr & SCTLR_A) {
>>+return true;
>>+}
>>+
>>+/*
>>+ * If translation is disabled, then the default memory type is
>>+ * Device(-nGnRnE) instead of Normal, which requires that alignment
>>+ * be enforced.  Since this affects all ram, it is most efficient
>>+ * to handle this during translation.
>>+ */
>>+if (sctlr & SCTLR_M) {
>>+/* Translation enabled: memory type in PTE via MAIR_ELx. */
>>+return false;
>>+}
>>+if (el < 2 && (arm_hcr_el2_eff(env) & (HCR_DC | HCR_VM))) {
>>+/* Stage 2 translation enabled: memory type in PTE. */
>>+return false;
>>+}
>>+return true;
>>+#endif
>>+}
>>+
>> static CPUARMTBFlags rebuild_hflags_common(CPUARMState *env, int fp_el,
>>ARMMMUIdx mmu_idx,
>>CPUARMTBFlags flags)
>>@@ -121,8 +150,9 @@ static CPUARMTBFlags rebuild_hflags_a32(CPUARMState *env, 
>>int fp_el,

Re: [PULL 17/20] target/arm: Do memory type alignment check when translation disabled

2024-05-25 Thread Bernhard Beschow



Am 5. März 2024 13:52:34 UTC schrieb Peter Maydell :
>From: Richard Henderson 
>
>If translation is disabled, the default memory type is Device, which
>requires alignment checking.  This is more optimally done early via
>the MemOp given to the TCG memory operation.
>
>Reviewed-by: Philippe Mathieu-Daudé 
>Reported-by: Idan Horowitz 
>Signed-off-by: Richard Henderson 
>Message-id: 20240301204110.656742-6-richard.hender...@linaro.org
>Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1204
>Signed-off-by: Richard Henderson 
>Signed-off-by: Peter Maydell 

Hi,

This change causes an old 4.14.40 Linux kernel to panic on boot using the 
sabrelite machine:

[snip]
Alignment trap: init (1) PC=0x76f1e3d4 Instr=0x14913004 Address=0x76f34f3e FSR 
0x001
Alignment trap: init (1) PC=0x76f1e3d8 Instr=0x148c3004 Address=0x7e8492bd FSR 
0x801
Alignment trap: init (1) PC=0x76f0dab0 Instr=0x6823 Address=0x7e849fbb FSR 0x001
Alignment trap: init (1) PC=0x76f0dab2 Instr=0x6864 Address=0x7e849fbf FSR 0x001
scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK2.5+ PQ: 0 ANSI: 5
fsl-asoc-card sound: ASoC: CODEC DAI sgtl5000 not registered
imx-sgtl5000 sound: ASoC: CODEC DAI sgtl5000 not registered
imx-sgtl5000 sound: snd_soc_register_card failed (-517)
Alignment trap: init (1) PC=0x76eac95a Instr=0xf8dd5015 Address=0x7e849b05 FSR 
0x001
Alignment trap: not handling instruction f8dd5015 at [<76eac95a>]
Unhandled fault: alignment exception (0x001) at 0x7e849b05
pgd = 9c59c000
[7e849b05] *pgd=2c552831, *pte=109eb34f, *ppte=109eb83f
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007

---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007

As you can see, some alignment exceptions are handled by the kernel, the last 
one isn't. I added some additional printk()'s and traced it down to this 
location in the kernel: 
 
which claims that ARMv6++ CPUs can handle up to word-sized unaligned accesses, 
thus no fixup is needed.

I hope that this will be sufficient for a fix. Let me know if you need any 
additional information.

Best regards,
Bernhard

>---
> target/arm/tcg/hflags.c | 34 --
> 1 file changed, 32 insertions(+), 2 deletions(-)
>
>diff --git a/target/arm/tcg/hflags.c b/target/arm/tcg/hflags.c
>index 8e5d35d9227..5da1b0fc1d4 100644
>--- a/target/arm/tcg/hflags.c
>+++ b/target/arm/tcg/hflags.c
>@@ -26,6 +26,35 @@ static inline bool fgt_svc(CPUARMState *env, int el)
> FIELD_EX64(env->cp15.fgt_exec[FGTREG_HFGITR], HFGITR_EL2, SVC_EL1);
> }
> 
>+/* Return true if memory alignment should be enforced. */
>+static bool aprofile_require_alignment(CPUARMState *env, int el, uint64_t 
>sctlr)
>+{
>+#ifdef CONFIG_USER_ONLY
>+return false;
>+#else
>+/* Check the alignment enable bit. */
>+if (sctlr & SCTLR_A) {
>+return true;
>+}
>+
>+/*
>+ * If translation is disabled, then the default memory type is
>+ * Device(-nGnRnE) instead of Normal, which requires that alignment
>+ * be enforced.  Since this affects all ram, it is most efficient
>+ * to handle this during translation.
>+ */
>+if (sctlr & SCTLR_M) {
>+/* Translation enabled: memory type in PTE via MAIR_ELx. */
>+return false;
>+}
>+if (el < 2 && (arm_hcr_el2_eff(env) & (HCR_DC | HCR_VM))) {
>+/* Stage 2 translation enabled: memory type in PTE. */
>+return false;
>+}
>+return true;
>+#endif
>+}
>+
> static CPUARMTBFlags rebuild_hflags_common(CPUARMState *env, int fp_el,
>ARMMMUIdx mmu_idx,
>CPUARMTBFlags flags)
>@@ -121,8 +150,9 @@ static CPUARMTBFlags rebuild_hflags_a32(CPUARMState *env, 
>int fp_el,
> {
> CPUARMTBFlags flags = {};
> int el = arm_current_el(env);
>+uint64_t sctlr = arm_sctlr(env, el);
> 
>-if (arm_sctlr(env, el) & SCTLR_A) {
>+if (aprofile_require_alignment(env, el, sctlr)) {
> DP_TBFLAG_ANY(flags, ALIGN_MEM, 1);
> }
> 
>@@ -223,7 +253,7 @@ static CPUARMTBFlags rebuild_hflags_a64(CPUARMState *env, 
>int el, int fp_el,
> 
> sctlr = regime_sctlr(env, stage1);
> 
>-if (sctlr & SCTLR_A) {
>+if (aprofile_require_alignment(env, el, sctlr)) {
> DP_TBFLAG_ANY(flags, ALIGN_MEM, 1);
> }
> 



Re: [PATCH v2 3/3] meson: Drop the .fa library prefix

2024-05-23 Thread Bernhard Beschow



Am 22. Mai 2024 10:43:04 UTC schrieb Akihiko Odaki :
>The non-standard .fa library prefix breaks the link source

s/prefix/suffix/ in the commit message and subject.

Best regards,
Bernhard

>de-duplication done by Meson so drop it.
>
>The lack of link source de-duplication causes AddressSanitizer to
>complain ODR violations, and makes GNU ld abort when combined with
>clang's LTO.
>
>Previously, the non-standard prefix was necessary for fork-fuzzing.
>Meson wraps all standard-prefixed libraries with --start-group and
>--end-group. This made a fork-fuzz.ld linker script wrapped as well and
>broke builds. Commit d2e6f9272d33 ("fuzz: remove fork-fuzzing
>scaffolding") dropped fork-fuzzing so we can now restore the standard
>prefix.
>
>The occurances of the prefix was detected and removed by performing
>a tree-wide search with 'fa' and .fa (note the quotes and dot).
>
>Signed-off-by: Akihiko Odaki 
>---
> docs/devel/build-system.rst | 5 -
> stubs/blk-exp-close-all.c   | 2 +-
> .gitlab-ci.d/buildtest-template.yml | 2 --
> .gitlab-ci.d/buildtest.yml  | 2 --
> gdbstub/meson.build | 2 --
> tcg/meson.build | 2 --
> tests/Makefile.include  | 2 +-
> tests/qtest/libqos/meson.build  | 1 -
> 8 files changed, 2 insertions(+), 16 deletions(-)
>
>diff --git a/docs/devel/build-system.rst b/docs/devel/build-system.rst
>index 09caf2f8e199..5baf027b7614 100644
>--- a/docs/devel/build-system.rst
>+++ b/docs/devel/build-system.rst
>@@ -236,15 +236,10 @@ Subsystem sourcesets:
>   are then turned into static libraries as follows::
> 
> libchardev = static_library('chardev', chardev_ss.sources(),
>-name_suffix: 'fa',
> build_by_default: false)
> 
> chardev = declare_dependency(link_whole: libchardev)
> 
>-  As of Meson 0.55.1, the special ``.fa`` suffix should be used for everything
>-  that is used with ``link_whole``, to ensure that the link flags are placed
>-  correctly in the command line.
>-
> Target-independent emulator sourcesets:
>   Various general purpose helper code is compiled only once and
>   the .o files are linked into all output binaries that need it.
>diff --git a/stubs/blk-exp-close-all.c b/stubs/blk-exp-close-all.c
>index 1c7131676392..2f68e06d7d05 100644
>--- a/stubs/blk-exp-close-all.c
>+++ b/stubs/blk-exp-close-all.c
>@@ -1,7 +1,7 @@
> #include "qemu/osdep.h"
> #include "block/export.h"
> 
>-/* Only used in programs that support block exports (libblockdev.fa) */
>+/* Only used in programs that support block exports (libblockdev.a) */
> void blk_exp_close_all(void)
> {
> }
>diff --git a/.gitlab-ci.d/buildtest-template.yml 
>b/.gitlab-ci.d/buildtest-template.yml
>index 22045add8064..69e468a576ba 100644
>--- a/.gitlab-ci.d/buildtest-template.yml
>+++ b/.gitlab-ci.d/buildtest-template.yml
>@@ -45,10 +45,8 @@
> exclude:
>   - build/**/*.p
>   - build/**/*.a.p
>-  - build/**/*.fa.p
>   - build/**/*.c.o
>   - build/**/*.c.o.d
>-  - build/**/*.fa
> 
> .common_test_job_template:
>   extends: .base_job_template
>diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
>index cfdff175c389..c156e6f1d90e 100644
>--- a/.gitlab-ci.d/buildtest.yml
>+++ b/.gitlab-ci.d/buildtest.yml
>@@ -178,10 +178,8 @@ build-previous-qemu:
> exclude:
>   - build-previous/**/*.p
>   - build-previous/**/*.a.p
>-  - build-previous/**/*.fa.p
>   - build-previous/**/*.c.o
>   - build-previous/**/*.c.o.d
>-  - build-previous/**/*.fa
>   needs:
> job: amd64-opensuse-leap-container
>   variables:
>diff --git a/gdbstub/meson.build b/gdbstub/meson.build
>index da5721d8452b..c91e398ae726 100644
>--- a/gdbstub/meson.build
>+++ b/gdbstub/meson.build
>@@ -19,13 +19,11 @@ gdb_system_ss = gdb_system_ss.apply({})
> 
> libgdb_user = static_library('gdb_user',
>  gdb_user_ss.sources() + genh,
>- name_suffix: 'fa',
>  c_args: '-DCONFIG_USER_ONLY',
>  build_by_default: false)
> 
> libgdb_system = static_library('gdb_system',
> gdb_system_ss.sources() + genh,
>-name_suffix: 'fa',
> build_by_default: false)
> 
> gdb_user = declare_dependency(link_whole: libgdb_user)
>diff --git a/tcg/meson.build b/tcg/meson.build
>index 8251589fd4e9..f941413d5801 100644
>--- a/tcg/meson.build
>+++ b/tcg/meson.build
>@@ -31,7 +31,6 @@ tcg_ss = tcg_ss.apply({})
> 
> libtcg_user = static_library('tcg_user',
>  tcg_ss.sources() + genh,
>- name_suffix: 'fa',
>  c_args: '-DCONFIG_USER_ONLY',
>  build_by_default: false)
> 
>@@ -41,7 +40,6 @@ user_ss.add(tcg_user)
> 
> libtcg_system = static_library('tcg_system',
> 

Re: [PATCH] accel/tcg: Init tb size and icount before plugin_gen_tb_end

2024-05-22 Thread Bernhard Beschow



Am 21. Mai 2024 21:06:04 UTC schrieb Richard Henderson 
:
>When passing disassembly data to plugin callbacks,
>translator_st_len relies on db->tb->size having been set.
>
>Fixes: 4c833c60e047 ("disas: Use translator_st to get disassembly data")

Indeed! It even works better than ever by also fixing the range of the machine 
code. So:

Tested-by: Bernhard Beschow 

The only issue that remains is that the machine code is reversed, i.e. the 
first byte is output last. But that is a bug that existed before.

>Reported-by: Bernhard Beschow 
>Signed-off-by: Richard Henderson 
>---
> accel/tcg/translator.c | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/accel/tcg/translator.c b/accel/tcg/translator.c
>index c56967eecd..113edcffe3 100644
>--- a/accel/tcg/translator.c
>+++ b/accel/tcg/translator.c
>@@ -214,14 +214,14 @@ void translator_loop(CPUState *cpu, TranslationBlock 
>*tb, int *max_insns,
> set_can_do_io(db, true);
> tcg_ctx->emit_before_op = NULL;
> 
>+/* May be used by disas_log or plugin callbacks. */
>+tb->size = db->pc_next - db->pc_first;
>+tb->icount = db->num_insns;
>+
> if (plugin_enabled) {
> plugin_gen_tb_end(cpu, db->num_insns);
> }
> 
>-/* The disas_log hook may use these values rather than recompute.  */
>-tb->size = db->pc_next - db->pc_first;
>-tb->icount = db->num_insns;
>-
> if (qemu_loglevel_mask(CPU_LOG_TB_IN_ASM)
> && qemu_log_in_addr_range(db->pc_first)) {
> FILE *logfile = qemu_log_trylock();



Re: [PATCH v3 6/6] hw/i386/pc_sysfw: Alias rather than copy isa-bios region

2024-05-21 Thread Bernhard Beschow



Am 8. Mai 2024 17:55:07 UTC schrieb Bernhard Beschow :
>In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
>to the top of the 4G memory boundary. Do the same in the -pflash case, but only
>for new machine versions for migration compatibility. This establishes common
>behavior and makes pflash commands work in the "isa-bios" region which some
>real-world legacy bioses rely on.
>
>Note that in the sev_enabled() case, the "isa-bios" memory region in the 
>-pflash
>case will now also point to encrypted memory, just like it already does in the
>-bios case.
>
>When running `info mtree` before and after this commit with
>`qemu-system-x86_64 -S -drive \
>if=pflash,format=raw,readonly=on,file=/usr/share/qemu/bios-256k.bin` and 
>running
>`diff -u before.mtree after.mtree` results in the following changes in the
>memory tree:
>
>   --- before.mtree
>   +++ after.mtree
>   @@ -71,7 +71,7 @@
>- (prio -1, i/o): pci
>000a-000b (prio 1, i/o): vga-lowmem
>000c-000d (prio 1, rom): pc.rom
>   -  000e-000f (prio 1, rom): isa-bios
>   +  000e-000f (prio 1, romd): alias isa-bios 
> @system.flash0 0002-0003
>000a-000b (prio 1, i/o): alias smram-region 
> @pci 000a-000b
>000c-000c3fff (prio 1, i/o): alias pam-pci @pci 
> 000c-000c3fff
>000c4000-000c7fff (prio 1, i/o): alias pam-pci @pci 
> 000c4000-000c7fff
>   @@ -108,7 +108,7 @@
>- (prio -1, i/o): pci
>000a-000b (prio 1, i/o): vga-lowmem
>000c-000d (prio 1, rom): pc.rom
>   -  000e-000f (prio 1, rom): isa-bios
>   +  000e-000f (prio 1, romd): alias isa-bios 
> @system.flash0 0002-0003
>000a-000b (prio 1, i/o): alias smram-region 
> @pci 000a-000b
>000c-000c3fff (prio 1, i/o): alias pam-pci @pci 
> 000c-000c3fff
>000c4000-000c7fff (prio 1, i/o): alias pam-pci @pci 
> 000c4000-000c7fff
>   @@ -131,11 +131,14 @@
>   memory-region: pc.ram
>   -07ff (prio 0, ram): pc.ram
>
>   +memory-region: system.flash0
>   +  fffc- (prio 0, romd): system.flash0
>   +
>   memory-region: pci
>   - (prio -1, i/o): pci
>000a-000b (prio 1, i/o): vga-lowmem
>000c-000d (prio 1, rom): pc.rom
>   -000e-000f (prio 1, rom): isa-bios
>   +000e-000f (prio 1, romd): alias isa-bios 
> @system.flash0 0002-0003
>
>   memory-region: smram
>000a-000b (prio 0, ram): alias smram-low 
> @pc.ram 000a-000b
>
>Note that in both cases the "system" memory region contains the entry
>
>  fffc- (prio 0, romd): system.flash0
>
>but the "system.flash0" memory region only appears standalone when "isa-bios" 
>is
>an alias.
>
>Signed-off-by: Bernhard Beschow 

Ping

This is the only patch in this series which hasn't got an R-b tag yet (the 
others are already in master) and I'm not aware of any open issues.

Best regards,
Bernhard



Re: [PULL 19/34] disas: Use translator_st to get disassembly data

2024-05-20 Thread Bernhard Beschow



Am 15. Mai 2024 07:52:32 UTC schrieb Richard Henderson 
:
>Read from already translated pages, or saved mmio data.
>
>Reviewed-by: Philippe Mathieu-Daudé 
>Signed-off-by: Richard Henderson 
>---
> include/disas/disas.h |  5 +++--
> include/exec/translator.h |  4 ++--
> include/qemu/typedefs.h   |  1 +
> accel/tcg/translator.c|  2 +-
> disas/disas-common.c  | 14 --
> disas/disas-mon.c | 15 +++
> disas/disas-target.c  | 19 +--
> plugins/api.c |  4 ++--
> 8 files changed, 41 insertions(+), 23 deletions(-)

Hi,

this patch unfortunately breaks the "execlog" plugin which doesn't decode the 
mnemonics correctly any longer. When launching `qemu-system-x86_64 -plugin 
/path/to/qemu-build/contrib/plugins/libexeclog.so -d plugin`, it outputs either 
"addb %al, (%bx, %si)" or ".byte 0x00", regardless of which instruction was 
actually executed. It seems to invoke the disassembler on zero-initialized 
data. Reverting the patch fixes the problem.

Moreover, patch 11 in this pull request "[PULL 11/34] plugins: Use 
translator_st for qemu_plugin_insn_data" causes the plugin to not print the 
correct machine code any longer, instead just printing "0x0". I haven't 
investigated whether reverting that patch fixes the problem since it doesn't 
revert cleanly.

It would be nice if somebody could look into this since I'm also trying to hunt 
down an alignment problem in the ARM emulator introduced in 9.0 which now 
prevents my guest from booting, and the execlog plugin is one of the tools I 
use for investigation.

Best regards,
Bernhard



Re: [PATCH v3 0/6] X86: Alias isa-bios area and clean up

2024-05-14 Thread Bernhard Beschow



Am 8. Mai 2024 20:39:28 UTC schrieb BALATON Zoltan :
>On Wed, 8 May 2024, Bernhard Beschow wrote:
>> This series changes the "isa-bios" MemoryRegion to be an alias rather than a
>> copy in the pflash case. This fixes issuing pflash commands in the isa-bios
>> region which matches real hardware and which some real-world legacy bioses 
>> I'm
>> running rely on. Furthermore, aliasing in the isa-bios area is already the
>
>I wonder if this allows the guest to flash the bios now, replacing or breaking 
>it which may be a new security issue.

The bios can already be flashed, just from different addresses. This series 
just adds another alias region through which flashing will be possible. AFAICS 
it doesn't impose new security issues.

Ping... The last patch still needs an R-b, the other patches are already on 
master.

Best regards,
Bernhard

> If so this may need some machine property to enable it or is that not a 
> problem in practice?
>
>Regards,
>BALATON Zoltan
>
>> current behavior in the bios (a.k.a. ROM) case, so this series consolidates
>> behavior.
>> 
>> For migration compatibility the aliasing is only performed on new versions of
>> the q34 and pc machine types.
>> 
>> v3:
>> * Amend commit message with a diff of `info mtree` (Phil)
>> * Add comments for bios memory regions (Phil)
>> 
>> v2:
>> * Don't leak bios memory regions (Phil)
>> * Add compat machinery (Michael)
>> 
>> Testing done:
>> * `make check` with qemu-system-x86_64 (QEMU 8.2.2) installed. All tests
>>  including migration tests pass.
>> * `make check-avocado`
>> 
>> Best regards,
>> Bernhard
>> 
>> Bernhard Beschow (6):
>>  hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()
>>  hw/i386: Have x86_bios_rom_init() take X86MachineState rather than
>>MachineState
>>  hw/i386/x86: Don't leak "isa-bios" memory regions
>>  hw/i386/x86: Don't leak "pc.bios" memory region
>>  hw/i386/x86: Extract x86_isa_bios_init() from x86_bios_rom_init()
>>  hw/i386/pc_sysfw: Alias rather than copy isa-bios region
>> 
>> include/hw/i386/pc.h  |  1 +
>> include/hw/i386/x86.h | 17 +++-
>> hw/i386/microvm.c |  2 +-
>> hw/i386/pc.c  |  1 +
>> hw/i386/pc_piix.c |  3 +++
>> hw/i386/pc_q35.c  |  2 ++
>> hw/i386/pc_sysfw.c| 17 ++--
>> hw/i386/x86.c | 45 ++-
>> 8 files changed, 58 insertions(+), 30 deletions(-)
>> 
>> --
>> 2.45.0
>> 
>> 
>> 



Re: [PATCH 2/3] hw/timer/imx_gpt: Convert DPRINTF to trace events

2024-05-13 Thread Bernhard Beschow



Am 13. Mai 2024 11:30:04 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 13/5/24 12:11, Bernhard Beschow wrote:
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   hw/timer/imx_gpt.c| 18 +-
>>   hw/timer/trace-events |  6 ++
>>   2 files changed, 11 insertions(+), 13 deletions(-)
>
>
>> @@ -317,7 +310,7 @@ static uint64_t imx_gpt_read(void *opaque, hwaddr 
>> offset, unsigned size)
>>   break;
>>   }
>>   -DPRINTF("(%s) = 0x%08x\n", imx_gpt_reg_name(offset >> 2), reg_value);
>> +trace_imx_gpt_read(imx_gpt_reg_name(offset >> 2), reg_value);
>> return reg_value;
>>   }
>> @@ -384,8 +377,7 @@ static void imx_gpt_write(void *opaque, hwaddr offset, 
>> uint64_t value,
>>   IMXGPTState *s = IMX_GPT(opaque);
>>   uint32_t oldreg;
>>   -DPRINTF("(%s, value = 0x%08x)\n", imx_gpt_reg_name(offset >> 2),
>> -(uint32_t)value);
>> +trace_imx_gpt_write(imx_gpt_reg_name(offset >> 2), (uint32_t)value);
>
>
>> @@ -49,6 +49,12 @@ cmsdk_apb_dualtimer_read(uint64_t offset, uint64_t data, 
>> unsigned size) "CMSDK A
>>   cmsdk_apb_dualtimer_write(uint64_t offset, uint64_t data, unsigned size) 
>> "CMSDK APB dualtimer write: offset 0x%" PRIx64 " data 0x%" PRIx64 " size %u"
>>   cmsdk_apb_dualtimer_reset(void) "CMSDK APB dualtimer: reset"
>>   +# imx_gpt.c
>> +imx_gpt_set_freq(uint32_t clksrc, uint32_t freq) "Setting clksrc %d to %d 
>> Hz"
>
>'%d' is signed, for unsigned you want '%u'.

I'll respin.

Thanks,
Bernhard

>
>> +imx_gpt_read(const char *name, uint32_t value) "%s -> 0x%08x"
>> +imx_gpt_write(const char *name, uint32_t value) "%s <- 0x%08x"
>
>I'd avoid the cast and use uint64_t/PRIx64 here to KISS, regardless:
>Reviewed-by: Philippe Mathieu-Daudé 
>
>> +imx_gpt_timeout(void) ""
>> +
>



[PATCH 2/3] hw/timer/imx_gpt: Convert DPRINTF to trace events

2024-05-13 Thread Bernhard Beschow
Signed-off-by: Bernhard Beschow 
---
 hw/timer/imx_gpt.c| 18 +-
 hw/timer/trace-events |  6 ++
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/hw/timer/imx_gpt.c b/hw/timer/imx_gpt.c
index a8edaec867..3c3b044622 100644
--- a/hw/timer/imx_gpt.c
+++ b/hw/timer/imx_gpt.c
@@ -18,19 +18,12 @@
 #include "migration/vmstate.h"
 #include "qemu/module.h"
 #include "qemu/log.h"
+#include "trace.h"
 
 #ifndef DEBUG_IMX_GPT
 #define DEBUG_IMX_GPT 0
 #endif
 
-#define DPRINTF(fmt, args...) \
-do { \
-if (DEBUG_IMX_GPT) { \
-fprintf(stderr, "[%s]%s: " fmt , TYPE_IMX_GPT, \
- __func__, ##args); \
-} \
-} while (0)
-
 static const char *imx_gpt_reg_name(uint32_t reg)
 {
 switch (reg) {
@@ -145,7 +138,7 @@ static void imx_gpt_set_freq(IMXGPTState *s)
 s->freq = imx_ccm_get_clock_frequency(s->ccm,
   s->clocks[clksrc]) / (1 + s->pr);
 
-DPRINTF("Setting clksrc %d to frequency %d\n", clksrc, s->freq);
+trace_imx_gpt_set_freq(clksrc, s->freq);
 
 if (s->freq) {
 ptimer_set_freq(s->timer, s->freq);
@@ -317,7 +310,7 @@ static uint64_t imx_gpt_read(void *opaque, hwaddr offset, 
unsigned size)
 break;
 }
 
-DPRINTF("(%s) = 0x%08x\n", imx_gpt_reg_name(offset >> 2), reg_value);
+trace_imx_gpt_read(imx_gpt_reg_name(offset >> 2), reg_value);
 
 return reg_value;
 }
@@ -384,8 +377,7 @@ static void imx_gpt_write(void *opaque, hwaddr offset, 
uint64_t value,
 IMXGPTState *s = IMX_GPT(opaque);
 uint32_t oldreg;
 
-DPRINTF("(%s, value = 0x%08x)\n", imx_gpt_reg_name(offset >> 2),
-(uint32_t)value);
+trace_imx_gpt_write(imx_gpt_reg_name(offset >> 2), (uint32_t)value);
 
 switch (offset >> 2) {
 case 0:
@@ -485,7 +477,7 @@ static void imx_gpt_timeout(void *opaque)
 {
 IMXGPTState *s = IMX_GPT(opaque);
 
-DPRINTF("\n");
+trace_imx_gpt_timeout();
 
 s->sr |= s->next_int;
 s->next_int = 0;
diff --git a/hw/timer/trace-events b/hw/timer/trace-events
index de769f4b71..c9bcc85455 100644
--- a/hw/timer/trace-events
+++ b/hw/timer/trace-events
@@ -49,6 +49,12 @@ cmsdk_apb_dualtimer_read(uint64_t offset, uint64_t data, 
unsigned size) "CMSDK A
 cmsdk_apb_dualtimer_write(uint64_t offset, uint64_t data, unsigned size) 
"CMSDK APB dualtimer write: offset 0x%" PRIx64 " data 0x%" PRIx64 " size %u"
 cmsdk_apb_dualtimer_reset(void) "CMSDK APB dualtimer: reset"
 
+# imx_gpt.c
+imx_gpt_set_freq(uint32_t clksrc, uint32_t freq) "Setting clksrc %d to %d Hz"
+imx_gpt_read(const char *name, uint32_t value) "%s -> 0x%08x"
+imx_gpt_write(const char *name, uint32_t value) "%s <- 0x%08x"
+imx_gpt_timeout(void) ""
+
 # npcm7xx_timer.c
 npcm7xx_timer_read(const char *id, uint64_t offset, uint64_t value) " %s 
offset: 0x%04" PRIx64 " value 0x%08" PRIx64
 npcm7xx_timer_write(const char *id, uint64_t offset, uint64_t value) "%s 
offset: 0x%04" PRIx64 " value 0x%08" PRIx64
-- 
2.45.0




[PATCH 3/3] hw/watchdog/wdt_imx2: Remove redundant assignment

2024-05-13 Thread Bernhard Beschow
The same statement is executed unconditionally right before the if statement.

Cc: Guenter Roeck 
Signed-off-by: Bernhard Beschow 

---

The duplicate line may indicate a bug. I'm not familiar with the code, so this
patch may go into the wrong direction. Please check!
---
 hw/watchdog/wdt_imx2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/watchdog/wdt_imx2.c b/hw/watchdog/wdt_imx2.c
index 6452fc4721..f9a7ea287f 100644
--- a/hw/watchdog/wdt_imx2.c
+++ b/hw/watchdog/wdt_imx2.c
@@ -39,7 +39,6 @@ static void imx2_wdt_expired(void *opaque)
 
 /* Perform watchdog action if watchdog is enabled */
 if (s->wcr & IMX2_WDT_WCR_WDE) {
-s->wrsr = IMX2_WDT_WRSR_TOUT;
 watchdog_perform_action();
 }
 }
-- 
2.45.0




[PATCH 0/3] Trivial ARM changes

2024-05-13 Thread Bernhard Beschow
This series improves the tracing experience in two devices used in ARM context.
It also removes a duplicate statement in an IMX watchdog which may indicate a
bug (see comment underneath commit message).

Best regards,
Bernhard

Bernhard Beschow (3):
  hw/rtc/ds1338: Trace send and receive operations
  hw/timer/imx_gpt: Convert DPRINTF to trace events
  hw/watchdog/wdt_imx2: Remove redundant assignment

 hw/rtc/ds1338.c|  6 ++
 hw/timer/imx_gpt.c | 18 +-
 hw/watchdog/wdt_imx2.c |  1 -
 hw/rtc/trace-events|  4 
 hw/timer/trace-events  |  6 ++
 5 files changed, 21 insertions(+), 14 deletions(-)

-- 
2.45.0




[PATCH 1/3] hw/rtc/ds1338: Trace send and receive operations

2024-05-13 Thread Bernhard Beschow
Signed-off-by: Bernhard Beschow 
---
 hw/rtc/ds1338.c | 6 ++
 hw/rtc/trace-events | 4 
 2 files changed, 10 insertions(+)

diff --git a/hw/rtc/ds1338.c b/hw/rtc/ds1338.c
index e479661c39..ec1b6c40b1 100644
--- a/hw/rtc/ds1338.c
+++ b/hw/rtc/ds1338.c
@@ -17,6 +17,7 @@
 #include "qemu/module.h"
 #include "qom/object.h"
 #include "sysemu/rtc.h"
+#include "trace.h"
 
 /* Size of NVRAM including both the user-accessible area and the
  * secondary register area.
@@ -126,6 +127,9 @@ static uint8_t ds1338_recv(I2CSlave *i2c)
 uint8_t res;
 
 res  = s->nvram[s->ptr];
+
+trace_ds1338_recv(s->ptr, res);
+
 inc_regptr(s);
 return res;
 }
@@ -134,6 +138,8 @@ static int ds1338_send(I2CSlave *i2c, uint8_t data)
 {
 DS1338State *s = DS1338(i2c);
 
+trace_ds1338_send(s->ptr, data);
+
 if (s->addr_byte) {
 s->ptr = data & (NVRAM_SIZE - 1);
 s->addr_byte = false;
diff --git a/hw/rtc/trace-events b/hw/rtc/trace-events
index ebb311a5b0..8012afe102 100644
--- a/hw/rtc/trace-events
+++ b/hw/rtc/trace-events
@@ -22,6 +22,10 @@ pl031_set_alarm(uint32_t ticks) "alarm set for %u ticks"
 aspeed_rtc_read(uint64_t addr, uint64_t value) "addr 0x%02" PRIx64 " value 
0x%08" PRIx64
 aspeed_rtc_write(uint64_t addr, uint64_t value) "addr 0x%02" PRIx64 " value 
0x%08" PRIx64
 
+# ds1338.c
+ds1338_recv(uint32_t addr, uint8_t value) "[0x%" PRIx32 "] -> 0x%02" PRIx8
+ds1338_send(uint32_t addr, uint8_t value) "[0x%" PRIx32 "] <- 0x%02" PRIx8
+
 # m48t59.c
 m48txx_nvram_io_read(uint64_t addr, uint64_t value) "io read addr:0x%04" 
PRIx64 " value:0x%02" PRIx64
 m48txx_nvram_io_write(uint64_t addr, uint64_t value) "io write addr:0x%04" 
PRIx64 " value:0x%02" PRIx64
-- 
2.45.0




[PATCH] ui/sdl2: Allow host to power down screen

2024-05-12 Thread Bernhard Beschow
By default, SDL disables the screen saver which prevents the host from powering
down the screen even if the screen is locked. This results in draining the
battery needlessly when the host isn't connected to a wall charger. Fix that by
enabling the screen saver.

Signed-off-by: Bernhard Beschow 
---
 ui/sdl2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ui/sdl2.c b/ui/sdl2.c
index 4971963f00..0a0eb5a42d 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -874,6 +874,7 @@ static void sdl2_display_init(DisplayState *ds, 
DisplayOptions *o)
 SDL_SetHint(SDL_HINT_ALLOW_ALT_TAB_WHILE_GRABBED, "0");
 #endif
 SDL_SetHint(SDL_HINT_WINDOWS_NO_CLOSE_ON_ALT_F4, "1");
+SDL_EnableScreenSaver();
 memset(, 0, sizeof(info));
 SDL_VERSION();
 
-- 
2.45.0




Re: [PATCH v2 0/6] This series changes the "isa-bios" MemoryRegion to be an alias rather than a

2024-05-08 Thread Bernhard Beschow



Am 8. Mai 2024 14:53:49 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 30/4/24 17:06, Bernhard Beschow wrote:
>
>> Bernhard Beschow (6):
>>hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()
>>hw/i386: Have x86_bios_rom_init() take X86MachineState rather than
>>  MachineState
>>hw/i386/x86: Don't leak "isa-bios" memory regions
>
>Patches 1-3 queued.

Phil,

you requested comments on the bios attributes which clashes with patch 3. I've 
just sent a new iteration of my series with all your requests addressed, 
including the comments.

Best regards,
Bernhard



[PATCH v3 6/6] hw/i386/pc_sysfw: Alias rather than copy isa-bios region

2024-05-08 Thread Bernhard Beschow
In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
to the top of the 4G memory boundary. Do the same in the -pflash case, but only
for new machine versions for migration compatibility. This establishes common
behavior and makes pflash commands work in the "isa-bios" region which some
real-world legacy bioses rely on.

Note that in the sev_enabled() case, the "isa-bios" memory region in the -pflash
case will now also point to encrypted memory, just like it already does in the
-bios case.

When running `info mtree` before and after this commit with
`qemu-system-x86_64 -S -drive \
if=pflash,format=raw,readonly=on,file=/usr/share/qemu/bios-256k.bin` and running
`diff -u before.mtree after.mtree` results in the following changes in the
memory tree:

   --- before.mtree
   +++ after.mtree
   @@ -71,7 +71,7 @@
- (prio -1, i/o): pci
000a-000b (prio 1, i/o): vga-lowmem
000c-000d (prio 1, rom): pc.rom
   -  000e-000f (prio 1, rom): isa-bios
   +  000e-000f (prio 1, romd): alias isa-bios 
@system.flash0 0002-0003
000a-000b (prio 1, i/o): alias smram-region 
@pci 000a-000b
000c-000c3fff (prio 1, i/o): alias pam-pci @pci 
000c-000c3fff
000c4000-000c7fff (prio 1, i/o): alias pam-pci @pci 
000c4000-000c7fff
   @@ -108,7 +108,7 @@
- (prio -1, i/o): pci
000a-000b (prio 1, i/o): vga-lowmem
000c-000d (prio 1, rom): pc.rom
   -  000e-000f (prio 1, rom): isa-bios
   +  000e-000f (prio 1, romd): alias isa-bios 
@system.flash0 0002-0003
000a-000b (prio 1, i/o): alias smram-region 
@pci 000a-000b
000c-000c3fff (prio 1, i/o): alias pam-pci @pci 
000c-000c3fff
000c4000-000c7fff (prio 1, i/o): alias pam-pci @pci 
000c4000-000c7fff
   @@ -131,11 +131,14 @@
   memory-region: pc.ram
   -07ff (prio 0, ram): pc.ram

   +memory-region: system.flash0
   +  fffc- (prio 0, romd): system.flash0
   +
   memory-region: pci
   - (prio -1, i/o): pci
000a-000b (prio 1, i/o): vga-lowmem
000c-000d (prio 1, rom): pc.rom
   -000e-000f (prio 1, rom): isa-bios
   +000e-000f (prio 1, romd): alias isa-bios 
@system.flash0 0002-0003

   memory-region: smram
000a-000b (prio 0, ram): alias smram-low 
@pc.ram 000a-000b

Note that in both cases the "system" memory region contains the entry

  fffc- (prio 0, romd): system.flash0

but the "system.flash0" memory region only appears standalone when "isa-bios" is
an alias.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h | 1 +
 hw/i386/pc.c | 1 +
 hw/i386/pc_piix.c| 3 +++
 hw/i386/pc_q35.c | 2 ++
 hw/i386/pc_sysfw.c   | 8 +++-
 5 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index e52290916c..ad9c3d9ba8 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -119,6 +119,7 @@ struct PCMachineClass {
 bool enforce_aligned_dimm;
 bool broken_reserved_end;
 bool enforce_amd_1tb_hole;
+bool isa_bios_alias;
 
 /* generate legacy CPU hotplug AML */
 bool legacy_cpu_hotplug;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 46235466d7..4878705af7 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1812,6 +1812,7 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->has_reserved_memory = true;
 pcmc->enforce_aligned_dimm = true;
 pcmc->enforce_amd_1tb_hole = true;
+pcmc->isa_bios_alias = true;
 /* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
  * to be used at the moment, 32K should be enough for a while.  */
 pcmc->acpi_data_size = 0x2 + 0x8000;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8850c49c66..d4e9deb509 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -525,12 +525,15 @@ DEFINE_I440FX_MACHINE(v9_1, "pc-i440fx-9.1", NULL,
 
 static void pc_i440fx_9_0_machine_options(MachineClass *m)
 {
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
+
 pc_i440fx_9_1_machine_options(m);
 m->alias = NULL;
 m->is_default = false;
 
 c

[PATCH v3 5/6] hw/i386/x86: Extract x86_isa_bios_init() from x86_bios_rom_init()

2024-05-08 Thread Bernhard Beschow
The function is inspired by pc_isa_bios_init() and should eventually replace it.
Using x86_isa_bios_init() rather than pc_isa_bios_init() fixes pflash commands
to work in the isa-bios region.

While at it convert the magic number 0x10 (== 1MiB) to increase readability.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h |  2 ++
 hw/i386/x86.c | 25 -
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index 55c6809ae0..d7b7d3f3ce 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -129,6 +129,8 @@ void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev,
 void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp);
 
+void x86_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *isa_memory,
+   MemoryRegion *bios, bool read_only);
 void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw);
 
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 29167de97d..c61f4ebfa6 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1128,12 +1128,25 @@ void x86_load_linux(X86MachineState *x86ms,
 nb_option_roms++;
 }
 
+void x86_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *isa_memory,
+   MemoryRegion *bios, bool read_only)
+{
+uint64_t bios_size = memory_region_size(bios);
+uint64_t isa_bios_size = MIN(bios_size, 128 * KiB);
+
+memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
+ bios_size - isa_bios_size, isa_bios_size);
+memory_region_add_subregion_overlap(isa_memory, 1 * MiB - isa_bios_size,
+isa_bios, 1);
+memory_region_set_readonly(isa_bios, read_only);
+}
+
 void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw)
 {
 const char *bios_name;
 char *filename;
-int bios_size, isa_bios_size;
+int bios_size;
 ssize_t ret;
 
 /* BIOS load */
@@ -1171,14 +1184,8 @@ void x86_bios_rom_init(X86MachineState *x86ms, const 
char *default_firmware,
 g_free(filename);
 
 /* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = MIN(bios_size, 128 * KiB);
-memory_region_init_alias(>isa_bios, NULL, "isa-bios", >bios,
- bios_size - isa_bios_size, isa_bios_size);
-memory_region_add_subregion_overlap(rom_memory,
-0x10 - isa_bios_size,
->isa_bios,
-1);
-memory_region_set_readonly(>isa_bios, !isapc_ram_fw);
+x86_isa_bios_init(>isa_bios, rom_memory, >bios,
+  !isapc_ram_fw);
 
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
-- 
2.45.0




[PATCH v3 2/6] hw/i386: Have x86_bios_rom_init() take X86MachineState rather than MachineState

2024-05-08 Thread Bernhard Beschow
The function creates and leaks two MemoryRegion objects regarding the BIOS which
will be moved into X86MachineState in the next steps to avoid the leakage.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h | 2 +-
 hw/i386/microvm.c | 2 +-
 hw/i386/pc_sysfw.c| 4 ++--
 hw/i386/x86.c | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index 4dc30dcb4d..cb07618d19 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -116,7 +116,7 @@ void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev,
 void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp);
 
-void x86_bios_rom_init(MachineState *ms, const char *default_firmware,
+void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw);
 
 void x86_load_linux(X86MachineState *x86ms,
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index 61a772dfe6..fec63cacfa 100644
--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -278,7 +278,7 @@ static void microvm_devices_init(MicrovmMachineState *mms)
 default_firmware = x86_machine_is_acpi_enabled(x86ms)
 ? MICROVM_BIOS_FILENAME
 : MICROVM_QBOOT_FILENAME;
-x86_bios_rom_init(MACHINE(mms), default_firmware, get_system_memory(), 
true);
+x86_bios_rom_init(x86ms, default_firmware, get_system_memory(), true);
 }
 
 static void microvm_memory_init(MicrovmMachineState *mms)
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 87b5bf59d6..59c7a81692 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -205,7 +205,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
 BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
 
 if (!pcmc->pci_enabled) {
-x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, true);
+x86_bios_rom_init(X86_MACHINE(pcms), "bios.bin", rom_memory, true);
 return;
 }
 
@@ -226,7 +226,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
 
 if (!pflash_blk[0]) {
 /* Machine property pflash0 not set, use ROM mode */
-x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, false);
+x86_bios_rom_init(X86_MACHINE(pcms), "bios.bin", rom_memory, false);
 } else {
 if (kvm_enabled() && !kvm_readonly_mem_enabled()) {
 /*
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 2a4f3ee285..6d3c72f124 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1128,7 +1128,7 @@ void x86_load_linux(X86MachineState *x86ms,
 nb_option_roms++;
 }
 
-void x86_bios_rom_init(MachineState *ms, const char *default_firmware,
+void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw)
 {
 const char *bios_name;
@@ -1138,7 +1138,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 ssize_t ret;
 
 /* BIOS load */
-bios_name = ms->firmware ?: default_firmware;
+bios_name = MACHINE(x86ms)->firmware ?: default_firmware;
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
 if (filename) {
 bios_size = get_image_size(filename);
-- 
2.45.0




[PATCH v3 4/6] hw/i386/x86: Don't leak "pc.bios" memory region

2024-05-08 Thread Bernhard Beschow
Fix the leaking in x86_bios_rom_init() by adding a "bios" attribute to
X86MachineState. Note that it is only used in the -bios case.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h |  6 ++
 hw/i386/x86.c | 13 ++---
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index a07de79167..55c6809ae0 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -53,6 +53,12 @@ struct X86MachineState {
 GMappedFile *initrd_mapped_file;
 HotplugHandler *acpi_dev;
 
+/*
+ * Map the whole BIOS just underneath the 4 GiB address boundary. Only used
+ * in the ROM (-bios) case.
+ */
+MemoryRegion bios;
+
 /*
  * Map the upper 128 KiB of the BIOS just underneath the 1 MiB address
  * boundary.
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 457e8a34a5..29167de97d 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1133,7 +1133,6 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 {
 const char *bios_name;
 char *filename;
-MemoryRegion *bios;
 int bios_size, isa_bios_size;
 ssize_t ret;
 
@@ -1149,8 +1148,8 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 (bios_size % 65536) != 0) {
 goto bios_error;
 }
-bios = g_malloc(sizeof(*bios));
-memory_region_init_ram(bios, NULL, "pc.bios", bios_size, _fatal);
+memory_region_init_ram(>bios, NULL, "pc.bios", bios_size,
+   _fatal);
 if (sev_enabled()) {
 /*
  * The concept of a "reset" simply doesn't exist for
@@ -1159,11 +1158,11 @@ void x86_bios_rom_init(X86MachineState *x86ms, const 
char *default_firmware,
  * the firmware as rom to properly re-initialize on reset.
  * Just go for a straight file load instead.
  */
-void *ptr = memory_region_get_ram_ptr(bios);
+void *ptr = memory_region_get_ram_ptr(>bios);
 load_image_size(filename, ptr, bios_size);
 x86_firmware_configure(ptr, bios_size);
 } else {
-memory_region_set_readonly(bios, !isapc_ram_fw);
+memory_region_set_readonly(>bios, !isapc_ram_fw);
 ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
 if (ret != 0) {
 goto bios_error;
@@ -1173,7 +1172,7 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 
 /* map the last 128KB of the BIOS in ISA space */
 isa_bios_size = MIN(bios_size, 128 * KiB);
-memory_region_init_alias(>isa_bios, NULL, "isa-bios", bios,
+memory_region_init_alias(>isa_bios, NULL, "isa-bios", >bios,
  bios_size - isa_bios_size, isa_bios_size);
 memory_region_add_subregion_overlap(rom_memory,
 0x10 - isa_bios_size,
@@ -1184,7 +1183,7 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
 (uint32_t)(-bios_size),
-bios);
+>bios);
 return;
 
 bios_error:
-- 
2.45.0




[PATCH v3 1/6] hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()

2024-05-08 Thread Bernhard Beschow
Given that memory_region_set_readonly() is a no-op when the readonlyness is
already as requested it is possible to simplify the pattern

  if (condition) {
foo(true);
  }

to

  foo(condition);

which is shorter and allows to see the invariant of the code more easily.

Signed-off-by: Bernhard Beschow 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/i386/x86.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 3d5b51e92d..2a4f3ee285 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1163,9 +1163,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 load_image_size(filename, ptr, bios_size);
 x86_firmware_configure(ptr, bios_size);
 } else {
-if (!isapc_ram_fw) {
-memory_region_set_readonly(bios, true);
-}
+memory_region_set_readonly(bios, !isapc_ram_fw);
 ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
 if (ret != 0) {
 goto bios_error;
@@ -1182,9 +1180,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 0x10 - isa_bios_size,
 isa_bios,
 1);
-if (!isapc_ram_fw) {
-memory_region_set_readonly(isa_bios, true);
-}
+memory_region_set_readonly(isa_bios, !isapc_ram_fw);
 
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
-- 
2.45.0




[PATCH v3 3/6] hw/i386/x86: Don't leak "isa-bios" memory regions

2024-05-08 Thread Bernhard Beschow
Fix the leaking in x86_bios_rom_init() and pc_isa_bios_init() by adding an
"isa_bios" attribute to X86MachineState.

Suggested-by: Philippe Mathieu-Daudé 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h | 7 +++
 hw/i386/pc_sysfw.c| 7 +++
 hw/i386/x86.c | 9 -
 3 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index cb07618d19..a07de79167 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -18,6 +18,7 @@
 #define HW_I386_X86_H
 
 #include "exec/hwaddr.h"
+#include "exec/memory.h"
 
 #include "hw/boards.h"
 #include "hw/intc/ioapic.h"
@@ -52,6 +53,12 @@ struct X86MachineState {
 GMappedFile *initrd_mapped_file;
 HotplugHandler *acpi_dev;
 
+/*
+ * Map the upper 128 KiB of the BIOS just underneath the 1 MiB address
+ * boundary.
+ */
+MemoryRegion isa_bios;
+
 /* RAM information (sizes, addresses, configuration): */
 ram_addr_t below_4g_mem_size, above_4g_mem_size;
 
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 59c7a81692..82d37cb376 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -40,11 +40,10 @@
 
 #define FLASH_SECTOR_SIZE 4096
 
-static void pc_isa_bios_init(MemoryRegion *rom_memory,
+static void pc_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *rom_memory,
  MemoryRegion *flash_mem)
 {
 int isa_bios_size;
-MemoryRegion *isa_bios;
 uint64_t flash_size;
 void *flash_ptr, *isa_bios_ptr;
 
@@ -52,7 +51,6 @@ static void pc_isa_bios_init(MemoryRegion *rom_memory,
 
 /* map the last 128KB of the BIOS in ISA space */
 isa_bios_size = MIN(flash_size, 128 * KiB);
-isa_bios = g_malloc(sizeof(*isa_bios));
 memory_region_init_ram(isa_bios, NULL, "isa-bios", isa_bios_size,
_fatal);
 memory_region_add_subregion_overlap(rom_memory,
@@ -136,6 +134,7 @@ void pc_system_flash_cleanup_unused(PCMachineState *pcms)
 static void pc_system_flash_map(PCMachineState *pcms,
 MemoryRegion *rom_memory)
 {
+X86MachineState *x86ms = X86_MACHINE(pcms);
 hwaddr total_size = 0;
 int i;
 BlockBackend *blk;
@@ -185,7 +184,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
 
 if (i == 0) {
 flash_mem = pflash_cfi01_get_memory(system_flash);
-pc_isa_bios_init(rom_memory, flash_mem);
+pc_isa_bios_init(>isa_bios, rom_memory, flash_mem);
 
 /* Encrypt the pflash boot ROM */
 if (sev_enabled()) {
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 6d3c72f124..457e8a34a5 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1133,7 +1133,7 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 {
 const char *bios_name;
 char *filename;
-MemoryRegion *bios, *isa_bios;
+MemoryRegion *bios;
 int bios_size, isa_bios_size;
 ssize_t ret;
 
@@ -1173,14 +1173,13 @@ void x86_bios_rom_init(X86MachineState *x86ms, const 
char *default_firmware,
 
 /* map the last 128KB of the BIOS in ISA space */
 isa_bios_size = MIN(bios_size, 128 * KiB);
-isa_bios = g_malloc(sizeof(*isa_bios));
-memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
+memory_region_init_alias(>isa_bios, NULL, "isa-bios", bios,
  bios_size - isa_bios_size, isa_bios_size);
 memory_region_add_subregion_overlap(rom_memory,
 0x10 - isa_bios_size,
-isa_bios,
+>isa_bios,
 1);
-memory_region_set_readonly(isa_bios, !isapc_ram_fw);
+memory_region_set_readonly(>isa_bios, !isapc_ram_fw);
 
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
-- 
2.45.0




[PATCH v3 0/6] X86: Alias isa-bios area and clean up

2024-05-08 Thread Bernhard Beschow
This series changes the "isa-bios" MemoryRegion to be an alias rather than a
copy in the pflash case. This fixes issuing pflash commands in the isa-bios
region which matches real hardware and which some real-world legacy bioses I'm
running rely on. Furthermore, aliasing in the isa-bios area is already the
current behavior in the bios (a.k.a. ROM) case, so this series consolidates
behavior.

For migration compatibility the aliasing is only performed on new versions of
the q34 and pc machine types.

v3:
* Amend commit message with a diff of `info mtree` (Phil)
* Add comments for bios memory regions (Phil)

v2:
* Don't leak bios memory regions (Phil)
* Add compat machinery (Michael)

Testing done:
* `make check` with qemu-system-x86_64 (QEMU 8.2.2) installed. All tests
  including migration tests pass.
* `make check-avocado`

Best regards,
Bernhard

Bernhard Beschow (6):
  hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()
  hw/i386: Have x86_bios_rom_init() take X86MachineState rather than
MachineState
  hw/i386/x86: Don't leak "isa-bios" memory regions
  hw/i386/x86: Don't leak "pc.bios" memory region
  hw/i386/x86: Extract x86_isa_bios_init() from x86_bios_rom_init()
  hw/i386/pc_sysfw: Alias rather than copy isa-bios region

 include/hw/i386/pc.h  |  1 +
 include/hw/i386/x86.h | 17 +++-
 hw/i386/microvm.c |  2 +-
 hw/i386/pc.c  |  1 +
 hw/i386/pc_piix.c |  3 +++
 hw/i386/pc_q35.c  |  2 ++
 hw/i386/pc_sysfw.c| 17 ++--
 hw/i386/x86.c | 45 ++-
 8 files changed, 58 insertions(+), 30 deletions(-)

-- 
2.45.0




Re: [PATCH v2 6/6] hw/i386/pc_sysfw: Alias rather than copy isa-bios region

2024-05-08 Thread Bernhard Beschow



Am 30. April 2024 15:39:21 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 30/4/24 17:06, Bernhard Beschow wrote:
>> In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
>> to the top of the 4G memory boundary. Do the same in the -pflash case, but 
>> only
>> for new machine versions for migration compatibility. This establishes common
>> behavior and makes pflash commands work in the "isa-bios" region which some
>> real-world legacy bioses rely on.
>
>Can you amend a diff of 'info mtree' here to see how the layout changes?

Will do.

Right now I have to manually sort the output to get a minimal diff. Is there a 
way to get a stable ordering of the memory regions? How would one fix that if 
this is currently impossible? With stable orderings we could have automated 
memory map tests which had been handy in the past.

>
>> Note that in the sev_enabled() case, the "isa-bios" memory region in the 
>> -pflash
>> case will now also point to encrypted memory, just like it already does in 
>> the
>> -bios case.
>> 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   include/hw/i386/pc.h | 1 +
>>   hw/i386/pc.c | 1 +
>>   hw/i386/pc_piix.c| 3 +++
>>   hw/i386/pc_q35.c | 2 ++
>>   hw/i386/pc_sysfw.c   | 8 +++-
>>   5 files changed, 14 insertions(+), 1 deletion(-)
>
>I'm still not convinced we need a migration back compat for this...

A copy behaves different than an alias, thus there is a behavioral change. 
Whether it really matters in practice for the kind of guests we care about I 
can't tell. Therefore I'd keep the compat machinery.

Best regards,
Bernhard

>
>> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
>> index 82d37cb376..ac88ad4eb9 100644
>> --- a/hw/i386/pc_sysfw.c
>> +++ b/hw/i386/pc_sysfw.c
>> @@ -135,6 +135,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
>>   MemoryRegion *rom_memory)
>>   {
>>   X86MachineState *x86ms = X86_MACHINE(pcms);
>> +PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>>   hwaddr total_size = 0;
>>   int i;
>>   BlockBackend *blk;
>> @@ -184,7 +185,12 @@ static void pc_system_flash_map(PCMachineState *pcms,
>> if (i == 0) {
>>   flash_mem = pflash_cfi01_get_memory(system_flash);
>> -pc_isa_bios_init(>isa_bios, rom_memory, flash_mem);
>> +if (pcmc->isa_bios_alias) {
>> +x86_isa_bios_init(>isa_bios, rom_memory, flash_mem,
>> +  true);
>> +} else {
>> +pc_isa_bios_init(>isa_bios, rom_memory, flash_mem);
>> +}
>> /* Encrypt the pflash boot ROM */
>>   if (sev_enabled()) {
>



[PATCH v2 6/6] hw/i386/pc_sysfw: Alias rather than copy isa-bios region

2024-04-30 Thread Bernhard Beschow
In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
to the top of the 4G memory boundary. Do the same in the -pflash case, but only
for new machine versions for migration compatibility. This establishes common
behavior and makes pflash commands work in the "isa-bios" region which some
real-world legacy bioses rely on.

Note that in the sev_enabled() case, the "isa-bios" memory region in the -pflash
case will now also point to encrypted memory, just like it already does in the
-bios case.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h | 1 +
 hw/i386/pc.c | 1 +
 hw/i386/pc_piix.c| 3 +++
 hw/i386/pc_q35.c | 2 ++
 hw/i386/pc_sysfw.c   | 8 +++-
 5 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index e52290916c..ad9c3d9ba8 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -119,6 +119,7 @@ struct PCMachineClass {
 bool enforce_aligned_dimm;
 bool broken_reserved_end;
 bool enforce_amd_1tb_hole;
+bool isa_bios_alias;
 
 /* generate legacy CPU hotplug AML */
 bool legacy_cpu_hotplug;
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 08c7de416f..ce61bb7fc1 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1811,6 +1811,7 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->has_reserved_memory = true;
 pcmc->enforce_aligned_dimm = true;
 pcmc->enforce_amd_1tb_hole = true;
+pcmc->isa_bios_alias = true;
 /* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
  * to be used at the moment, 32K should be enough for a while.  */
 pcmc->acpi_data_size = 0x2 + 0x8000;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8850c49c66..d4e9deb509 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -525,12 +525,15 @@ DEFINE_I440FX_MACHINE(v9_1, "pc-i440fx-9.1", NULL,
 
 static void pc_i440fx_9_0_machine_options(MachineClass *m)
 {
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
+
 pc_i440fx_9_1_machine_options(m);
 m->alias = NULL;
 m->is_default = false;
 
 compat_props_add(m->compat_props, hw_compat_9_0, hw_compat_9_0_len);
 compat_props_add(m->compat_props, pc_compat_9_0, pc_compat_9_0_len);
+pcmc->isa_bios_alias = false;
 }
 
 DEFINE_I440FX_MACHINE(v9_0, "pc-i440fx-9.0", NULL,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index bb53a51ac1..bd7db4abac 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -378,10 +378,12 @@ DEFINE_Q35_MACHINE(v9_1, "pc-q35-9.1", NULL,
 
 static void pc_q35_9_0_machine_options(MachineClass *m)
 {
+PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_q35_9_1_machine_options(m);
 m->alias = NULL;
 compat_props_add(m->compat_props, hw_compat_9_0, hw_compat_9_0_len);
 compat_props_add(m->compat_props, pc_compat_9_0, pc_compat_9_0_len);
+pcmc->isa_bios_alias = false;
 }
 
 DEFINE_Q35_MACHINE(v9_0, "pc-q35-9.0", NULL,
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 82d37cb376..ac88ad4eb9 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -135,6 +135,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
 MemoryRegion *rom_memory)
 {
 X86MachineState *x86ms = X86_MACHINE(pcms);
+PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 hwaddr total_size = 0;
 int i;
 BlockBackend *blk;
@@ -184,7 +185,12 @@ static void pc_system_flash_map(PCMachineState *pcms,
 
 if (i == 0) {
 flash_mem = pflash_cfi01_get_memory(system_flash);
-pc_isa_bios_init(>isa_bios, rom_memory, flash_mem);
+if (pcmc->isa_bios_alias) {
+x86_isa_bios_init(>isa_bios, rom_memory, flash_mem,
+  true);
+} else {
+pc_isa_bios_init(>isa_bios, rom_memory, flash_mem);
+}
 
 /* Encrypt the pflash boot ROM */
 if (sev_enabled()) {
-- 
2.45.0




[PATCH v2 2/6] hw/i386: Have x86_bios_rom_init() take X86MachineState rather than MachineState

2024-04-30 Thread Bernhard Beschow
The function creates and leaks two MemoryRegion objects regarding the BIOS which
will be moved into X86MachineState in the next steps to avoid the leakage.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h | 2 +-
 hw/i386/microvm.c | 2 +-
 hw/i386/pc_sysfw.c| 4 ++--
 hw/i386/x86.c | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index 4dc30dcb4d..cb07618d19 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -116,7 +116,7 @@ void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev,
 void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp);
 
-void x86_bios_rom_init(MachineState *ms, const char *default_firmware,
+void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw);
 
 void x86_load_linux(X86MachineState *x86ms,
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index 61a772dfe6..fec63cacfa 100644
--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -278,7 +278,7 @@ static void microvm_devices_init(MicrovmMachineState *mms)
 default_firmware = x86_machine_is_acpi_enabled(x86ms)
 ? MICROVM_BIOS_FILENAME
 : MICROVM_QBOOT_FILENAME;
-x86_bios_rom_init(MACHINE(mms), default_firmware, get_system_memory(), 
true);
+x86_bios_rom_init(x86ms, default_firmware, get_system_memory(), true);
 }
 
 static void microvm_memory_init(MicrovmMachineState *mms)
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 87b5bf59d6..59c7a81692 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -205,7 +205,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
 BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
 
 if (!pcmc->pci_enabled) {
-x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, true);
+x86_bios_rom_init(X86_MACHINE(pcms), "bios.bin", rom_memory, true);
 return;
 }
 
@@ -226,7 +226,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
 
 if (!pflash_blk[0]) {
 /* Machine property pflash0 not set, use ROM mode */
-x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, false);
+x86_bios_rom_init(X86_MACHINE(pcms), "bios.bin", rom_memory, false);
 } else {
 if (kvm_enabled() && !kvm_readonly_mem_enabled()) {
 /*
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 2a4f3ee285..6d3c72f124 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1128,7 +1128,7 @@ void x86_load_linux(X86MachineState *x86ms,
 nb_option_roms++;
 }
 
-void x86_bios_rom_init(MachineState *ms, const char *default_firmware,
+void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw)
 {
 const char *bios_name;
@@ -1138,7 +1138,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 ssize_t ret;
 
 /* BIOS load */
-bios_name = ms->firmware ?: default_firmware;
+bios_name = MACHINE(x86ms)->firmware ?: default_firmware;
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
 if (filename) {
 bios_size = get_image_size(filename);
-- 
2.45.0




[PATCH v2 3/6] hw/i386/x86: Don't leak "isa-bios" memory regions

2024-04-30 Thread Bernhard Beschow
Fix the leaking in x86_bios_rom_init() and pc_isa_bios_init() by adding an
"isa_bios" attribute to X86MachineState.

Suggested-by: Philippe Mathieu-Daudé 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h | 2 ++
 hw/i386/pc_sysfw.c| 7 +++
 hw/i386/x86.c | 9 -
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index cb07618d19..271ad50470 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -18,6 +18,7 @@
 #define HW_I386_X86_H
 
 #include "exec/hwaddr.h"
+#include "exec/memory.h"
 
 #include "hw/boards.h"
 #include "hw/intc/ioapic.h"
@@ -51,6 +52,7 @@ struct X86MachineState {
 DeviceState *ioapic2;
 GMappedFile *initrd_mapped_file;
 HotplugHandler *acpi_dev;
+MemoryRegion isa_bios;
 
 /* RAM information (sizes, addresses, configuration): */
 ram_addr_t below_4g_mem_size, above_4g_mem_size;
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 59c7a81692..82d37cb376 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -40,11 +40,10 @@
 
 #define FLASH_SECTOR_SIZE 4096
 
-static void pc_isa_bios_init(MemoryRegion *rom_memory,
+static void pc_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *rom_memory,
  MemoryRegion *flash_mem)
 {
 int isa_bios_size;
-MemoryRegion *isa_bios;
 uint64_t flash_size;
 void *flash_ptr, *isa_bios_ptr;
 
@@ -52,7 +51,6 @@ static void pc_isa_bios_init(MemoryRegion *rom_memory,
 
 /* map the last 128KB of the BIOS in ISA space */
 isa_bios_size = MIN(flash_size, 128 * KiB);
-isa_bios = g_malloc(sizeof(*isa_bios));
 memory_region_init_ram(isa_bios, NULL, "isa-bios", isa_bios_size,
_fatal);
 memory_region_add_subregion_overlap(rom_memory,
@@ -136,6 +134,7 @@ void pc_system_flash_cleanup_unused(PCMachineState *pcms)
 static void pc_system_flash_map(PCMachineState *pcms,
 MemoryRegion *rom_memory)
 {
+X86MachineState *x86ms = X86_MACHINE(pcms);
 hwaddr total_size = 0;
 int i;
 BlockBackend *blk;
@@ -185,7 +184,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
 
 if (i == 0) {
 flash_mem = pflash_cfi01_get_memory(system_flash);
-pc_isa_bios_init(rom_memory, flash_mem);
+pc_isa_bios_init(>isa_bios, rom_memory, flash_mem);
 
 /* Encrypt the pflash boot ROM */
 if (sev_enabled()) {
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 6d3c72f124..457e8a34a5 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1133,7 +1133,7 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 {
 const char *bios_name;
 char *filename;
-MemoryRegion *bios, *isa_bios;
+MemoryRegion *bios;
 int bios_size, isa_bios_size;
 ssize_t ret;
 
@@ -1173,14 +1173,13 @@ void x86_bios_rom_init(X86MachineState *x86ms, const 
char *default_firmware,
 
 /* map the last 128KB of the BIOS in ISA space */
 isa_bios_size = MIN(bios_size, 128 * KiB);
-isa_bios = g_malloc(sizeof(*isa_bios));
-memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
+memory_region_init_alias(>isa_bios, NULL, "isa-bios", bios,
  bios_size - isa_bios_size, isa_bios_size);
 memory_region_add_subregion_overlap(rom_memory,
 0x10 - isa_bios_size,
-isa_bios,
+>isa_bios,
 1);
-memory_region_set_readonly(isa_bios, !isapc_ram_fw);
+memory_region_set_readonly(>isa_bios, !isapc_ram_fw);
 
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
-- 
2.45.0




[PATCH v2 5/6] hw/i386/x86: Extract x86_isa_bios_init() from x86_bios_rom_init()

2024-04-30 Thread Bernhard Beschow
The function is inspired by pc_isa_bios_init() and should eventually replace it.
Using x86_isa_bios_init() rather than pc_isa_bios_init() fixes pflash commands
to work in the isa-bios region.

While at it convert the magic number 0x10 (== 1MiB) to increase readability.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h |  2 ++
 hw/i386/x86.c | 25 -
 2 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index fb41263b9d..e92a226d13 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -119,6 +119,8 @@ void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev,
 void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp);
 
+void x86_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *isa_memory,
+   MemoryRegion *bios, bool read_only);
 void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw);
 
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 29167de97d..c61f4ebfa6 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1128,12 +1128,25 @@ void x86_load_linux(X86MachineState *x86ms,
 nb_option_roms++;
 }
 
+void x86_isa_bios_init(MemoryRegion *isa_bios, MemoryRegion *isa_memory,
+   MemoryRegion *bios, bool read_only)
+{
+uint64_t bios_size = memory_region_size(bios);
+uint64_t isa_bios_size = MIN(bios_size, 128 * KiB);
+
+memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
+ bios_size - isa_bios_size, isa_bios_size);
+memory_region_add_subregion_overlap(isa_memory, 1 * MiB - isa_bios_size,
+isa_bios, 1);
+memory_region_set_readonly(isa_bios, read_only);
+}
+
 void x86_bios_rom_init(X86MachineState *x86ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw)
 {
 const char *bios_name;
 char *filename;
-int bios_size, isa_bios_size;
+int bios_size;
 ssize_t ret;
 
 /* BIOS load */
@@ -1171,14 +1184,8 @@ void x86_bios_rom_init(X86MachineState *x86ms, const 
char *default_firmware,
 g_free(filename);
 
 /* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = MIN(bios_size, 128 * KiB);
-memory_region_init_alias(>isa_bios, NULL, "isa-bios", >bios,
- bios_size - isa_bios_size, isa_bios_size);
-memory_region_add_subregion_overlap(rom_memory,
-0x10 - isa_bios_size,
->isa_bios,
-1);
-memory_region_set_readonly(>isa_bios, !isapc_ram_fw);
+x86_isa_bios_init(>isa_bios, rom_memory, >bios,
+  !isapc_ram_fw);
 
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
-- 
2.45.0




[PATCH v2 0/6] This series changes the "isa-bios" MemoryRegion to be an alias rather than a

2024-04-30 Thread Bernhard Beschow
region which matches real hardware and which some real-world legacy bioses I'm
running rely on. Furthermore, aliasing in the isa-bios area is already the
current behavior in the bios (a.k.a. ROM) case, so this series consolidates
behavior.

For migration compatibility the aliasing is only performed on new versions of
the q34 and pc machine types.

v2:
* Don't leak bios memory regions (Phil)
* Add compat machinery (Michael)

Testing done:
* `make check` with qemu-system-x86_64 (QEMU 8.2.2) installed. All tests
  including migration tests pass.
* `make check-avocado`

Best regards,
Bernhard

Bernhard Beschow (6):
  hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()
  hw/i386: Have x86_bios_rom_init() take X86MachineState rather than
MachineState
  hw/i386/x86: Don't leak "isa-bios" memory regions
  hw/i386/x86: Don't leak "pc.bios" memory region
  hw/i386/x86: Extract x86_isa_bios_init() from x86_bios_rom_init()
  hw/i386/pc_sysfw: Alias rather than copy isa-bios region

 include/hw/i386/pc.h  |  1 +
 include/hw/i386/x86.h |  7 ++-
 hw/i386/microvm.c |  2 +-
 hw/i386/pc.c  |  1 +
 hw/i386/pc_piix.c |  3 +++
 hw/i386/pc_q35.c  |  2 ++
 hw/i386/pc_sysfw.c| 17 ++--
 hw/i386/x86.c | 45 ++-
 8 files changed, 48 insertions(+), 30 deletions(-)

-- 
2.45.0




[PATCH v2 4/6] hw/i386/x86: Don't leak "pc.bios" memory region

2024-04-30 Thread Bernhard Beschow
Fix the leaking in x86_bios_rom_init() by adding a "bios" attribute to
X86MachineState. Note that it is only used in the -bios case.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h |  1 +
 hw/i386/x86.c | 13 ++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index 271ad50470..fb41263b9d 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -52,6 +52,7 @@ struct X86MachineState {
 DeviceState *ioapic2;
 GMappedFile *initrd_mapped_file;
 HotplugHandler *acpi_dev;
+MemoryRegion bios;
 MemoryRegion isa_bios;
 
 /* RAM information (sizes, addresses, configuration): */
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 457e8a34a5..29167de97d 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1133,7 +1133,6 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 {
 const char *bios_name;
 char *filename;
-MemoryRegion *bios;
 int bios_size, isa_bios_size;
 ssize_t ret;
 
@@ -1149,8 +1148,8 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 (bios_size % 65536) != 0) {
 goto bios_error;
 }
-bios = g_malloc(sizeof(*bios));
-memory_region_init_ram(bios, NULL, "pc.bios", bios_size, _fatal);
+memory_region_init_ram(>bios, NULL, "pc.bios", bios_size,
+   _fatal);
 if (sev_enabled()) {
 /*
  * The concept of a "reset" simply doesn't exist for
@@ -1159,11 +1158,11 @@ void x86_bios_rom_init(X86MachineState *x86ms, const 
char *default_firmware,
  * the firmware as rom to properly re-initialize on reset.
  * Just go for a straight file load instead.
  */
-void *ptr = memory_region_get_ram_ptr(bios);
+void *ptr = memory_region_get_ram_ptr(>bios);
 load_image_size(filename, ptr, bios_size);
 x86_firmware_configure(ptr, bios_size);
 } else {
-memory_region_set_readonly(bios, !isapc_ram_fw);
+memory_region_set_readonly(>bios, !isapc_ram_fw);
 ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
 if (ret != 0) {
 goto bios_error;
@@ -1173,7 +1172,7 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 
 /* map the last 128KB of the BIOS in ISA space */
 isa_bios_size = MIN(bios_size, 128 * KiB);
-memory_region_init_alias(>isa_bios, NULL, "isa-bios", bios,
+memory_region_init_alias(>isa_bios, NULL, "isa-bios", >bios,
  bios_size - isa_bios_size, isa_bios_size);
 memory_region_add_subregion_overlap(rom_memory,
 0x10 - isa_bios_size,
@@ -1184,7 +1183,7 @@ void x86_bios_rom_init(X86MachineState *x86ms, const char 
*default_firmware,
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
 (uint32_t)(-bios_size),
-bios);
+>bios);
 return;
 
 bios_error:
-- 
2.45.0




[PATCH v2 1/6] hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()

2024-04-30 Thread Bernhard Beschow
Given that memory_region_set_readonly() is a no-op when the readonlyness is
already as requested it is possible to simplify the pattern

  if (condition) {
foo(true);
  }

to

  foo(condition);

which is shorter and allows to see the invariant of the code more easily.

Signed-off-by: Bernhard Beschow 
Reviewed-by: Philippe Mathieu-Daudé 
---
 hw/i386/x86.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 3d5b51e92d..2a4f3ee285 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1163,9 +1163,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 load_image_size(filename, ptr, bios_size);
 x86_firmware_configure(ptr, bios_size);
 } else {
-if (!isapc_ram_fw) {
-memory_region_set_readonly(bios, true);
-}
+memory_region_set_readonly(bios, !isapc_ram_fw);
 ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
 if (ret != 0) {
 goto bios_error;
@@ -1182,9 +1180,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 0x10 - isa_bios_size,
 isa_bios,
 1);
-if (!isapc_ram_fw) {
-memory_region_set_readonly(isa_bios, true);
-}
+memory_region_set_readonly(isa_bios, !isapc_ram_fw);
 
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
-- 
2.45.0




Re: [PATCH 4/4] hw/i386: Consolidate isa-bios creation

2024-04-26 Thread Bernhard Beschow



Am 25. April 2024 07:19:27 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Hi Bernhard,
>
>On 22/4/24 22:06, Bernhard Beschow wrote:
>> Now that the -bios and -pflash code paths work the same it is possible to 
>> have a
>> common implementation.
>> 
>> While at it convert the magic number 0x10 (== 1MiB) to increase 
>> readability.
>> 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   include/hw/i386/x86.h |  2 ++
>>   hw/i386/pc_sysfw.c| 28 
>>   hw/i386/x86.c | 29 ++---
>>   3 files changed, 24 insertions(+), 35 deletions(-)
>
>
>> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
>> index 6e89671c26..e529182b48 100644
>> --- a/hw/i386/pc_sysfw.c
>> +++ b/hw/i386/pc_sysfw.c
>> @@ -28,7 +28,6 @@
>>   #include "sysemu/block-backend.h"
>>   #include "qemu/error-report.h"
>>   #include "qemu/option.h"
>> -#include "qemu/units.h"
>>   #include "hw/sysbus.h"
>>   #include "hw/i386/x86.h"
>>   #include "hw/i386/pc.h"
>> @@ -40,27 +39,6 @@
>> #define FLASH_SECTOR_SIZE 4096
>>   -static void pc_isa_bios_init(MemoryRegion *rom_memory,
>> - MemoryRegion *flash_mem)
>> -{
>> -int isa_bios_size;
>> -MemoryRegion *isa_bios;
>> -uint64_t flash_size;
>> -
>> -flash_size = memory_region_size(flash_mem);
>> -
>> -/* map the last 128KB of the BIOS in ISA space */
>> -isa_bios_size = MIN(flash_size, 128 * KiB);
>> -isa_bios = g_malloc(sizeof(*isa_bios));
>> -memory_region_init_alias(isa_bios, NULL, "isa-bios", flash_mem,
>> - flash_size - isa_bios_size, isa_bios_size);
>> -memory_region_add_subregion_overlap(rom_memory,
>> -0x10 - isa_bios_size,
>> -isa_bios,
>> -1);
>> -memory_region_set_readonly(isa_bios, true);
>> -}
>
>
>> diff --git a/hw/i386/x86.c b/hw/i386/x86.c
>> index 32cd22a4a8..7366b0cee4 100644
>> --- a/hw/i386/x86.c
>> +++ b/hw/i386/x86.c
>> @@ -1136,13 +1136,28 @@ void x86_load_linux(X86MachineState *x86ms,
>>   nb_option_roms++;
>>   }
>>   +void x86_isa_bios_init(MemoryRegion *rom_memory, MemoryRegion *bios,
>> +   bool isapc_ram_fw)
>> +{
>> +int bios_size = memory_region_size(bios);
>> +int isa_bios_size = MIN(bios_size, 128 * KiB);
>> +MemoryRegion *isa_bios;
>> +
>> +isa_bios = g_malloc(sizeof(*isa_bios));
>
>Pre-existing, but we shouldn't leak MR like that.
>
>Probably better to pass pre-allocated as argument,
>smth like:
>
>  /**
>   * x86_isa_bios_init: ... at fixed addr ...
>   * @isa_bios: MR to initialize
>   * @isa_mr: ISA bus
>   * @bios: BIOS MR to map on ISA bus
>   * @read_only: Map the BIOS as read-only
>   */
>  void x86_isa_bios_init(MemoryRegion *isa_bios,
> const MemoryRegion *isa_mr,
> const MemoryRegion *bios,
> bool read_only);
>

Same would apply for the "pc.bios" region. I'll fix both then.

Best regards,
Bernhard

>> +memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
>> + bios_size - isa_bios_size, isa_bios_size);
>> +memory_region_add_subregion_overlap(rom_memory, 1 * MiB - isa_bios_size,
>> +isa_bios, 1);
>> +memory_region_set_readonly(isa_bios, !isapc_ram_fw);
>> +}
>



Re: [PATCH 0/4] X86: Alias isa-bios area and clean up

2024-04-26 Thread Bernhard Beschow



Am 25. April 2024 08:07:43 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 22/4/24 22:06, Bernhard Beschow wrote:
>> This series changes the "isa-bios" MemoryRegion to be an alias rather than a
>> copy in the pflash case. This fixes issuing pflash commands in the isa-bios
>> region which matches real hardware and which some real-world legacy bioses 
>> I'm
>> running rely on. Furthermore, aliasing in the isa-bios area is already the
>> current behavior in the bios (a.k.a. ROM) case, so this series consolidates
>> behavior.
>
>
>> Bernhard Beschow (4):
>>hw/i386/pc_sysfw: Remove unused parameter from pc_isa_bios_init()
>
>To reduce respin churn, I'm queuing the first patch via hw-misc.

Nice!



Re: [PATCH 0/4] X86: Alias isa-bios area and clean up

2024-04-26 Thread Bernhard Beschow



Am 25. April 2024 10:16:10 UTC schrieb "Michael S. Tsirkin" :
>On Mon, Apr 22, 2024 at 10:06:21PM +0200, Bernhard Beschow wrote:
>> This series changes the "isa-bios" MemoryRegion to be an alias rather than a
>> copy in the pflash case. This fixes issuing pflash commands in the isa-bios
>> region which matches real hardware and which some real-world legacy bioses 
>> I'm
>> running rely on. Furthermore, aliasing in the isa-bios area is already the
>> current behavior in the bios (a.k.a. ROM) case, so this series consolidates
>> behavior.
>> 
>> The consolidateion results in duplicate code which is resolved in the second
>> half (patches 3 and 4) in this series.
>> 
>> Question: AFAIU, patch 2 changes the behavior for SEV-enabled guests since 
>> the
>> isa-bios area is now encrypted. Does this need compat machinery or is it a
>> bugfix?
>
>When in doubt, do a compat thing.

Will do.

Thanks,
Bernhard

>
>> Testing done:
>> * `make check` with qemu-system-x86_64 (QEMU 8.2.2) installed. All tests
>>   including migration tests pass.
>> * `make check-avocado`
>> 
>> Best regards,
>> Bernhard
>> 
>> Bernhard Beschow (4):
>>   hw/i386/pc_sysfw: Remove unused parameter from pc_isa_bios_init()
>>   hw/i386/pc_sysfw: Alias rather than copy isa-bios region
>>   hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()
>>   hw/i386: Consolidate isa-bios creation
>> 
>>  include/hw/i386/x86.h |  2 ++
>>  hw/i386/pc_sysfw.c| 38 --
>>  hw/i386/x86.c | 35 +++
>>  3 files changed, 25 insertions(+), 50 deletions(-)
>> 
>> -- 
>> 2.44.0
>> 
>



Re: [PATCH 0/4] X86: Alias isa-bios area and clean up

2024-04-24 Thread Bernhard Beschow
+Michael 

Am 22. April 2024 20:06:21 UTC schrieb Bernhard Beschow :
>This series changes the "isa-bios" MemoryRegion to be an alias rather than a
>
>copy in the pflash case. This fixes issuing pflash commands in the isa-bios
>
>region which matches real hardware and which some real-world legacy bioses I'm
>
>running rely on. Furthermore, aliasing in the isa-bios area is already the
>
>current behavior in the bios (a.k.a. ROM) case, so this series consolidates
>
>behavior.
>
>
>
>The consolidateion results in duplicate code which is resolved in the second
>
>half (patches 3 and 4) in this series.
>
>
>
>Question: AFAIU, patch 2 changes the behavior for SEV-enabled guests since the
>
>isa-bios area is now encrypted. Does this need compat machinery or is it a
>
>bugfix?
>
>
>
>Testing done:
>
>* `make check` with qemu-system-x86_64 (QEMU 8.2.2) installed. All tests
>
>  including migration tests pass.
>
>* `make check-avocado`
>
>
>
>Best regards,
>
>Bernhard
>
>
>
>Bernhard Beschow (4):
>
>  hw/i386/pc_sysfw: Remove unused parameter from pc_isa_bios_init()
>
>  hw/i386/pc_sysfw: Alias rather than copy isa-bios region
>
>  hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()
>
>  hw/i386: Consolidate isa-bios creation
>
>
>
> include/hw/i386/x86.h |  2 ++
>
> hw/i386/pc_sysfw.c| 38 --
>
> hw/i386/x86.c | 35 +++
>
> 3 files changed, 25 insertions(+), 50 deletions(-)
>
>
>
>-- >
>2.44.0
>
>
>



[PATCH 3/4] hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()

2024-04-22 Thread Bernhard Beschow
Given that memory_region_set_readonly() is a no-op when the readonlyness is
already as requested it is possible to simplify the pattern

  if (condition) {
foo(true);
  }

to

  foo(condition);

which is shorter and allows to see the invariant of the code more easily.

Signed-off-by: Bernhard Beschow 
---
 hw/i386/x86.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index ffbda48917..32cd22a4a8 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1171,9 +1171,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 load_image_size(filename, ptr, bios_size);
 x86_firmware_configure(ptr, bios_size);
 } else {
-if (!isapc_ram_fw) {
-memory_region_set_readonly(bios, true);
-}
+memory_region_set_readonly(bios, !isapc_ram_fw);
 ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
 if (ret != 0) {
 goto bios_error;
@@ -1190,9 +1188,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 0x10 - isa_bios_size,
 isa_bios,
 1);
-if (!isapc_ram_fw) {
-memory_region_set_readonly(isa_bios, true);
-}
+memory_region_set_readonly(isa_bios, !isapc_ram_fw);
 
 /* map all the bios at the top of memory */
 memory_region_add_subregion(rom_memory,
-- 
2.44.0




[PATCH 0/4] X86: Alias isa-bios area and clean up

2024-04-22 Thread Bernhard Beschow
This series changes the "isa-bios" MemoryRegion to be an alias rather than a
copy in the pflash case. This fixes issuing pflash commands in the isa-bios
region which matches real hardware and which some real-world legacy bioses I'm
running rely on. Furthermore, aliasing in the isa-bios area is already the
current behavior in the bios (a.k.a. ROM) case, so this series consolidates
behavior.

The consolidateion results in duplicate code which is resolved in the second
half (patches 3 and 4) in this series.

Question: AFAIU, patch 2 changes the behavior for SEV-enabled guests since the
isa-bios area is now encrypted. Does this need compat machinery or is it a
bugfix?

Testing done:
* `make check` with qemu-system-x86_64 (QEMU 8.2.2) installed. All tests
  including migration tests pass.
* `make check-avocado`

Best regards,
Bernhard

Bernhard Beschow (4):
  hw/i386/pc_sysfw: Remove unused parameter from pc_isa_bios_init()
  hw/i386/pc_sysfw: Alias rather than copy isa-bios region
  hw/i386/x86: Eliminate two if statements in x86_bios_rom_init()
  hw/i386: Consolidate isa-bios creation

 include/hw/i386/x86.h |  2 ++
 hw/i386/pc_sysfw.c| 38 --
 hw/i386/x86.c | 35 +++
 3 files changed, 25 insertions(+), 50 deletions(-)

-- 
2.44.0




[PATCH 4/4] hw/i386: Consolidate isa-bios creation

2024-04-22 Thread Bernhard Beschow
Now that the -bios and -pflash code paths work the same it is possible to have a
common implementation.

While at it convert the magic number 0x10 (== 1MiB) to increase readability.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/x86.h |  2 ++
 hw/i386/pc_sysfw.c| 28 
 hw/i386/x86.c | 29 ++---
 3 files changed, 24 insertions(+), 35 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index 4dc30dcb4d..8e6ba4a726 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -116,6 +116,8 @@ void x86_cpu_unplug_request_cb(HotplugHandler *hotplug_dev,
 void x86_cpu_unplug_cb(HotplugHandler *hotplug_dev,
DeviceState *dev, Error **errp);
 
+void x86_isa_bios_init(MemoryRegion *rom_memory, MemoryRegion *bios,
+   bool isapc_ram_fw);
 void x86_bios_rom_init(MachineState *ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw);
 
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 6e89671c26..e529182b48 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -28,7 +28,6 @@
 #include "sysemu/block-backend.h"
 #include "qemu/error-report.h"
 #include "qemu/option.h"
-#include "qemu/units.h"
 #include "hw/sysbus.h"
 #include "hw/i386/x86.h"
 #include "hw/i386/pc.h"
@@ -40,27 +39,6 @@
 
 #define FLASH_SECTOR_SIZE 4096
 
-static void pc_isa_bios_init(MemoryRegion *rom_memory,
- MemoryRegion *flash_mem)
-{
-int isa_bios_size;
-MemoryRegion *isa_bios;
-uint64_t flash_size;
-
-flash_size = memory_region_size(flash_mem);
-
-/* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = MIN(flash_size, 128 * KiB);
-isa_bios = g_malloc(sizeof(*isa_bios));
-memory_region_init_alias(isa_bios, NULL, "isa-bios", flash_mem,
- flash_size - isa_bios_size, isa_bios_size);
-memory_region_add_subregion_overlap(rom_memory,
-0x10 - isa_bios_size,
-isa_bios,
-1);
-memory_region_set_readonly(isa_bios, true);
-}
-
 static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
  const char *name,
  const char *alias_prop_name)
@@ -121,7 +99,7 @@ void pc_system_flash_cleanup_unused(PCMachineState *pcms)
  * pcms->max_fw_size.
  *
  * If pcms->flash[0] has a block backend, its memory is passed to
- * pc_isa_bios_init().  Merging several flash devices for isa-bios is
+ * x86_isa_bios_init(). Merging several flash devices for isa-bios is
  * not supported.
  */
 static void pc_system_flash_map(PCMachineState *pcms,
@@ -176,7 +154,9 @@ static void pc_system_flash_map(PCMachineState *pcms,
 
 if (i == 0) {
 flash_mem = pflash_cfi01_get_memory(system_flash);
-pc_isa_bios_init(rom_memory, flash_mem);
+
+/* Map the last 128KB of the BIOS in ISA space */
+x86_isa_bios_init(rom_memory, flash_mem, false);
 
 /* Encrypt the pflash boot ROM */
 if (sev_enabled()) {
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 32cd22a4a8..7366b0cee4 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -1136,13 +1136,28 @@ void x86_load_linux(X86MachineState *x86ms,
 nb_option_roms++;
 }
 
+void x86_isa_bios_init(MemoryRegion *rom_memory, MemoryRegion *bios,
+   bool isapc_ram_fw)
+{
+int bios_size = memory_region_size(bios);
+int isa_bios_size = MIN(bios_size, 128 * KiB);
+MemoryRegion *isa_bios;
+
+isa_bios = g_malloc(sizeof(*isa_bios));
+memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
+ bios_size - isa_bios_size, isa_bios_size);
+memory_region_add_subregion_overlap(rom_memory, 1 * MiB - isa_bios_size,
+isa_bios, 1);
+memory_region_set_readonly(isa_bios, !isapc_ram_fw);
+}
+
 void x86_bios_rom_init(MachineState *ms, const char *default_firmware,
MemoryRegion *rom_memory, bool isapc_ram_fw)
 {
 const char *bios_name;
 char *filename;
-MemoryRegion *bios, *isa_bios;
-int bios_size, isa_bios_size;
+MemoryRegion *bios;
+int bios_size;
 ssize_t ret;
 
 /* BIOS load */
@@ -1180,15 +1195,7 @@ void x86_bios_rom_init(MachineState *ms, const char 
*default_firmware,
 g_free(filename);
 
 /* map the last 128KB of the BIOS in ISA space */
-isa_bios_size = MIN(bios_size, 128 * KiB);
-isa_bios = g_malloc(sizeof(*isa_bios));
-memory_region_init_alias(isa_bios, NULL, "isa-bios", bios,
- bios_size - isa_bios_size, isa_bios_size);
-memory_

[PATCH 2/4] hw/i386/pc_sysfw: Alias rather than copy isa-bios region

2024-04-22 Thread Bernhard Beschow
In the -bios case the "isa-bios" memory region is an alias to the BIOS mapped
to the top of the 4G memory boundary. Do the same in the -pflash case to have
common behavior. This also makes pflash commands work in the "isa-bios" region
which some real-world legacy bioses rely on.

Note that in the sev_enabled() case, the "isa-bios" memory region in the -pflash
case will now also point to encrypted memory, just like it already does in the
-bios case.

Signed-off-by: Bernhard Beschow 
---
 hw/i386/pc_sysfw.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 87b5bf59d6..6e89671c26 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -46,27 +46,18 @@ static void pc_isa_bios_init(MemoryRegion *rom_memory,
 int isa_bios_size;
 MemoryRegion *isa_bios;
 uint64_t flash_size;
-void *flash_ptr, *isa_bios_ptr;
 
 flash_size = memory_region_size(flash_mem);
 
 /* map the last 128KB of the BIOS in ISA space */
 isa_bios_size = MIN(flash_size, 128 * KiB);
 isa_bios = g_malloc(sizeof(*isa_bios));
-memory_region_init_ram(isa_bios, NULL, "isa-bios", isa_bios_size,
-   _fatal);
+memory_region_init_alias(isa_bios, NULL, "isa-bios", flash_mem,
+ flash_size - isa_bios_size, isa_bios_size);
 memory_region_add_subregion_overlap(rom_memory,
 0x10 - isa_bios_size,
 isa_bios,
 1);
-
-/* copy ISA rom image from top of flash memory */
-flash_ptr = memory_region_get_ram_ptr(flash_mem);
-isa_bios_ptr = memory_region_get_ram_ptr(isa_bios);
-memcpy(isa_bios_ptr,
-   ((uint8_t*)flash_ptr) + (flash_size - isa_bios_size),
-   isa_bios_size);
-
 memory_region_set_readonly(isa_bios, true);
 }
 
-- 
2.44.0




[PATCH 1/4] hw/i386/pc_sysfw: Remove unused parameter from pc_isa_bios_init()

2024-04-22 Thread Bernhard Beschow
Signed-off-by: Bernhard Beschow 
---
 hw/i386/pc_sysfw.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index 3efabbbab2..87b5bf59d6 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -41,8 +41,7 @@
 #define FLASH_SECTOR_SIZE 4096
 
 static void pc_isa_bios_init(MemoryRegion *rom_memory,
- MemoryRegion *flash_mem,
- int ram_size)
+ MemoryRegion *flash_mem)
 {
 int isa_bios_size;
 MemoryRegion *isa_bios;
@@ -186,7 +185,7 @@ static void pc_system_flash_map(PCMachineState *pcms,
 
 if (i == 0) {
 flash_mem = pflash_cfi01_get_memory(system_flash);
-pc_isa_bios_init(rom_memory, flash_mem, size);
+pc_isa_bios_init(rom_memory, flash_mem);
 
 /* Encrypt the pflash boot ROM */
 if (sev_enabled()) {
-- 
2.44.0




Re: [PATCH v2 11/15] hw/southbridge/ich9: Add a AHCI function

2024-04-15 Thread Bernhard Beschow



Am 26. Februar 2024 11:14:10 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Instantiate TYPE_ICH9_AHCI in TYPE_ICH9_SOUTHBRIDGE.
>
>Since the PC machines can disable SATA (see the
>PC_MACHINE_SATA dynamic property), add the 'sata-enabled'
>property to disable it.
>
>Signed-off-by: Philippe Mathieu-Daudé 
>---
> MAINTAINERS   |  2 ++
> include/hw/southbridge/ich9.h |  4 
> hw/i386/pc_q35.c  | 21 +++--
> hw/southbridge/ich9.c | 35 +++
> hw/i386/Kconfig   |  1 -
> hw/southbridge/Kconfig|  1 +
> 6 files changed, 41 insertions(+), 23 deletions(-)
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 4576339053..7d1b3e0d99 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -2615,10 +2615,12 @@ M: Marcel Apfelbaum 
> S: Supported
> F: hw/acpi/ich9*.c
> F: hw/i2c/smbus_ich9.c
>+F: hw/ide/ich9_ahci.c
> F: hw/isa/lpc_ich9.c
> F: hw/southbridge/ich9.c
> F: include/hw/acpi/ich9*.h
> F: include/hw/i2c/ich9_smbus.h
>+F: include/hw/ide/ahci-pci.h
> F: include/hw/pci-bridge/ich9_dmi.h
> F: include/hw/southbridge/ich9.h
> 
>diff --git a/include/hw/southbridge/ich9.h b/include/hw/southbridge/ich9.h
>index b9122d299d..ac7f9f4ff5 100644
>--- a/include/hw/southbridge/ich9.h
>+++ b/include/hw/southbridge/ich9.h
>@@ -166,10 +166,6 @@ struct ICH9LPCState {
> 
> #define ICH9_GPIO_GSI "gsi"
> 
>-/* D31:F2 SATA Controller #1 */
>-#define ICH9_SATA1_DEV  31
>-#define ICH9_SATA1_FUNC 2
>-
> /* D31:F0 power management I/O registers
>offset from the address ICH9_LPC_PMBASE */
> 
>diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>index f951cf1e3a..6903719b97 100644
>--- a/hw/i386/pc_q35.c
>+++ b/hw/i386/pc_q35.c
>@@ -60,9 +60,6 @@
> #include "hw/i386/acpi-build.h"
> #include "target/i386/cpu.h"
> 
>-/* ICH9 AHCI has 6 ports */
>-#define MAX_SATA_PORTS 6
>-
> struct ehci_companions {
> const char *name;
> int func;
>@@ -134,7 +131,6 @@ static void pc_q35_init(MachineState *machine)
> ISABus *isa_bus;
> int i;
> ram_addr_t lowmem;
>-DriveInfo *hd[MAX_SATA_PORTS];
> MachineClass *mc = MACHINE_GET_CLASS(machine);
> bool acpi_pcihp;
> bool keep_pci_slot_hpc;
>@@ -227,6 +223,7 @@ static void pc_q35_init(MachineState *machine)
> object_property_set_link(OBJECT(ich9), "mch-pcie-bus",
>  OBJECT(pcms->pcibus), _abort);
> qdev_prop_set_bit(ich9, "d2p-enabled", false);
>+qdev_prop_set_bit(ich9, "sata-enabled", pcms->sata_enabled);
> qdev_realize_and_unref(ich9, NULL, _fatal);
> 
> /* create ISA bus */
>@@ -287,20 +284,8 @@ static void pc_q35_init(MachineState *machine)
>  0xff0104);
> 
> if (pcms->sata_enabled) {
>-PCIDevice *pdev;
>-AHCIPCIState *ich9;

The ahci include and perhaps all ide includes can be removed here.

Any plans for a v3?

Best regards,
Bernhard

>-
>-/* ahci and SATA device, for q35 1 ahci controller is built-in */
>-pdev = pci_create_simple_multifunction(pcms->pcibus,
>-   PCI_DEVFN(ICH9_SATA1_DEV,
>- ICH9_SATA1_FUNC),
>-   "ich9-ahci");
>-ich9 = ICH9_AHCI(pdev);
>-pcms->idebus[0] = qdev_get_child_bus(DEVICE(pdev), "ide.0");
>-pcms->idebus[1] = qdev_get_child_bus(DEVICE(pdev), "ide.1");
>-g_assert(MAX_SATA_PORTS == ich9->ahci.ports);
>-ide_drive_get(hd, ich9->ahci.ports);
>-ahci_ide_create_devs(>ahci, hd);
>+pcms->idebus[0] = qdev_get_child_bus(ich9, "ide.0");
>+pcms->idebus[1] = qdev_get_child_bus(ich9, "ide.1");
> }
> 
> if (machine_usb(machine)) {
>diff --git a/hw/southbridge/ich9.c b/hw/southbridge/ich9.c
>index 8c4356ff74..37255bb941 100644
>--- a/hw/southbridge/ich9.c
>+++ b/hw/southbridge/ich9.c
>@@ -13,22 +13,30 @@
> #include "hw/southbridge/ich9.h"
> #include "hw/pci/pci.h"
> #include "hw/pci-bridge/ich9_dmi.h"
>+#include "hw/ide/ahci-pci.h"
>+#include "hw/ide/ide-dev.h"
> 
> #define ICH9_D2P_DEVFN  PCI_DEVFN(30, 0)
>+#define ICH9_SATA1_DEVFNPCI_DEVFN(31, 2)
>+
>+#define SATA_PORTS  6
> 
> struct ICH9State {
> DeviceState parent_obj;
> 
> I82801b11Bridge d2p;
>+AHCIPCIState sata0;
> 
> PCIBus *pci_bus;
> bool d2p_enabled;
>+bool sata_enabled;
> };
> 
> static Property ich9_props[] = {
> DEFINE_PROP_LINK("mch-pcie-bus", ICH9State, pci_bus,
>  TYPE_PCIE_BUS, PCIBus *),
> DEFINE_PROP_BOOL("d2p-enabled", ICH9State, d2p_enabled, true),
>+DEFINE_PROP_BOOL("sata-enabled", ICH9State, sata_enabled, true),
> DEFINE_PROP_END_OF_LIST(),
> };
> 
>@@ -52,6 +60,29 @@ static bool ich9_realize_d2p(ICH9State *s, Error **errp)
> return true;
> }
> 
>+static bool ich9_realize_sata(ICH9State *s, Error **errp)
>+{
>+DriveInfo *hd[SATA_PORTS];

Re: [RFC PATCH-for-9.1 09/29] hw/i386/pc: Pass PCMachineState argument to acpi_setup()

2024-04-06 Thread Bernhard Beschow



Am 28. März 2024 15:54:17 UTC schrieb "Philippe Mathieu-Daudé" 
:
>acpi_setup() caller knows about the machine state, so pass
>it as argument to avoid a qdev_get_machine() call.
>
>We already resolved X86_MACHINE(pcms) as 'x86ms' so use the
>latter.
>
>Signed-off-by: Philippe Mathieu-Daudé 

This patch looks like good material on its own.

Reviewed-by: Bernhard Beschow 

>---
> hw/i386/acpi-build.h | 3 ++-
> hw/i386/acpi-build.c | 5 ++---
> hw/i386/pc.c | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/hw/i386/acpi-build.h b/hw/i386/acpi-build.h
>index 0dce155c8c..31de5bddbd 100644
>--- a/hw/i386/acpi-build.h
>+++ b/hw/i386/acpi-build.h
>@@ -2,6 +2,7 @@
> #ifndef HW_I386_ACPI_BUILD_H
> #define HW_I386_ACPI_BUILD_H
> #include "hw/acpi/acpi-defs.h"
>+#include "hw/i386/pc.h"
> 
> extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
> 
>@@ -9,7 +10,7 @@ extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
> #define ACPI_PCIHP_SEJ_BASE 0x8
> #define ACPI_PCIHP_BNMR_BASE 0x10
> 
>-void acpi_setup(void);
>+void acpi_setup(PCMachineState *pcms);
> Object *acpi_get_i386_pci_host(void);
> 
> #endif
>diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
>index 6e8e32e5d2..e702d5e9d2 100644
>--- a/hw/i386/acpi-build.c
>+++ b/hw/i386/acpi-build.c
>@@ -2749,9 +2749,8 @@ static const VMStateDescription vmstate_acpi_build = {
> },
> };
> 
>-void acpi_setup(void)
>+void acpi_setup(PCMachineState *pcms)
> {
>-PCMachineState *pcms = PC_MACHINE(qdev_get_machine());
> X86MachineState *x86ms = X86_MACHINE(pcms);
> AcpiBuildTables tables;
> AcpiBuildState *build_state;
>@@ -2771,7 +2770,7 @@ void acpi_setup(void)
> return;
> }
> 
>-if (!x86_machine_is_acpi_enabled(X86_MACHINE(pcms))) {
>+if (!x86_machine_is_acpi_enabled(x86ms)) {
> ACPI_BUILD_DPRINTF("ACPI disabled. Bailing out.\n");
> return;
> }
>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>index 6d87d1d4c2..dfc0247bb6 100644
>--- a/hw/i386/pc.c
>+++ b/hw/i386/pc.c
>@@ -601,7 +601,7 @@ void pc_machine_done(Notifier *notifier, void *data)
> /* set the number of CPUs */
> x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
> 
>-acpi_setup();
>+acpi_setup(pcms);
> if (x86ms->fw_cfg) {
> fw_cfg_build_smbios(pcms, x86ms->fw_cfg, 
> pcms->smbios_entry_point_type);
> fw_cfg_build_feature_control(MACHINE(pcms), x86ms->fw_cfg);



Re: [RFC PATCH-for-9.1 13/29] hw/i386/pc: Remove non-PCI code from pc_system_firmware_init()

2024-04-06 Thread Bernhard Beschow



Am 28. März 2024 15:54:21 UTC schrieb "Philippe Mathieu-Daudé" 
:
>x86_bios_rom_init() is the single non-PCI-machine call
>from pc_system_firmware_init(). Extract it to the caller.
>
>Signed-off-by: Philippe Mathieu-Daudé 
>---
> hw/i386/pc.c   | 6 +-
> hw/i386/pc_sysfw.c | 5 +
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>index f184808e3e..5b96daa414 100644
>--- a/hw/i386/pc.c
>+++ b/hw/i386/pc.c
>@@ -956,7 +956,11 @@ void pc_memory_init(PCMachineState *pcms,
> }
> 
> /* Initialize PC system firmware */
>-pc_system_firmware_init(pcms, rom_memory);
>+if (pci_enabled) {
>+pc_system_firmware_init(pcms, rom_memory);
>+} else {
>+x86_bios_rom_init(machine, "bios.bin", rom_memory, true);
>+}
> 
> option_rom_mr = g_malloc(sizeof(*option_rom_mr));
> memory_region_init_ram(option_rom_mr, NULL, "pc.rom", PC_ROM_SIZE,
>diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
>index 862a082b0a..541dcaef71 100644
>--- a/hw/i386/pc_sysfw.c
>+++ b/hw/i386/pc_sysfw.c
>@@ -202,10 +202,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
> int i;
> BlockBackend *pflash_blk[ARRAY_SIZE(pcms->flash)];
> 
>-if (!pc_machine_is_pci_enabled(pcms)) {
>-x86_bios_rom_init(MACHINE(pcms), "bios.bin", rom_memory, true);
>-return;
>-}
>+assert(pc_machine_is_pci_enabled(pcms));

AFAICS nothing refers to pci in the whole file any longer. The only reason for 
checking pci_enabled before seems for filtering out the x86_bios_rom_init() 
case. This has been moved to the caller. Can we thus drop the assert? This 
allows for further removal of code in this patch and avoids superficial 
barriers for reusing this code. Or do I miss something?

Anyway, this patch looks like good material on its own and could be tagged 
independently.

With dropping the assert considered:
Reviewed-by: Bernhard Beschow 

> 
> /* Map legacy -drive if=pflash to machine properties */
> for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {



Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-29 Thread Bernhard Beschow



Am 28. März 2024 14:09:52 UTC schrieb Mark Cave-Ayland 
:
>On 27/03/2024 07:09, Gerd Hoffmann wrote:
>
>> On Tue, Mar 26, 2024 at 01:30:48PM +, Mark Cave-Ayland wrote:
>>> Heh I've actually been using isapc over the past couple of weeks to fire up
>>> some old programs in a Windows 3 VM :)
>> 
>> I'm wondering why these use cases can't simply use the 'pc' machine
>> type?
>> 
>> The early pci chipsets of the 90-ies have been designed in a
>> backward-compatible manner, with devices such as the IDE controller
>> being mapped to the standard ISA ioports.  So even an historic OS which
>> does not know what PCI is can run on that hardware, by simply talking to
>> devices using the standard ISA io ports ...
>
>Hmmm that's a fair point: I think the pc machine has a PCI-ISA bridge 
>included, so ISA devices can be plugged in as needed. The reason I ended up on 
>that configuration was because I ended up chasing down a regression, and 
>wanted to quickly eliminate things such as ACPI.

In theory you could pass `-M acpi=off` to not instantiate the PIIX4 ACPI 
function, essentially turning the Frankenstein-PIIX4 SB into a PIIX3. However, 
this also removes SMI registers used by SeaBIOS to handle SMM setup which may 
create unwanted side effects. On a real PIIX3, these registers are located in 
the ISA function. I wonder if it made sense to implement that for greater 
compatibility.

What do you think? Gerd, what do you think w.r.t. SeaBIOS?

Best regards,
Bernhard

>
>
>ATB,
>
>Mark.
>
>



Re: [PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated

2024-03-27 Thread Bernhard Beschow



Am 26. März 2024 13:29:58 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Hi Igor,
>
>On 26/3/24 14:08, Thomas Huth wrote:
>> 
>> s/iaspc/isapc/ in the subject
>> 
>> On 26/03/2024 13.51, Igor Mammedov wrote:
>>> ISAPC machine was introduced 25 years ago and it's a lot of time since
>>> such machine was around with real ISA only PC hardware practically defunct.
>>> Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 
>>> host
>>> in only TCG mode, while in KVM mode it hung in the middle of boot)
>
>I'm quite opposed to this patch. QEMU models various very-old /
>defunct hardware. I'm pretty sure Bernhard and myself are OK to
>keep maintaining it, besides we are working in separating it from
>the i440fx+piix machine.

Yes, I'd rather keep maintaining the isapc machine and separating it from the 
i440fx machine seems like a good idea to me. I'm confident that we can work out 
a way that allows for moving forward the pc-pci machines while keeping the 
isapc machine from getting into the way too much.

Best regards,
Bernhard

> Also, this machine is particularly
>interesting for my single-binary experiments.
>
>Where I agree is we should stop reporting "KVM on ISA/PC machine"
>as supported.
>
>Regards,
>
>Phil.
>
>>> Rather than spending time on fixing 'the oldest' no longer tested machine 
>>> type,
>>> deprecate it so we can clean up QEMU code from legacy fixups and hopefully
>>> make it easier to follow.
>>> 
>>> Folks who have to use ancient guest that requires ISAPC can still
>>> use older QEMU to play with it.
>>> 
>>> Signed-off-by: Igor Mammedov 
>>> ---
>>>   docs/about/deprecated.rst | 7 +++
>>>   hw/i386/pc_piix.c | 1 +
>>>   2 files changed, 8 insertions(+)
>>> 
>>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>>> index 7b548519b5..5708296991 100644
>>> --- a/docs/about/deprecated.rst
>>> +++ b/docs/about/deprecated.rst
>>> @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays 
>>> and thus might have
>>>   various pitfalls with regards to live migration. Use a newer machine type
>>>   instead.
>>> +``isapc`` (since 9.0)
>>> +'
>>> +
>>> +These old machine type are quite neglected nowadays and thus might have
>> 
>> "This old machine type is ..." ?
>> 
>>> +various pitfalls with regards to live migration. Use a newer machine type
>>> +instead.
>> 
>> I doubt that isapc could ever be used reliably for live migration, since 
>> it's an unversioned machine type, so I think it would be better to not 
>> mention live migration here.
>> 
>>   Thomas
>> 
>> 
>



Re: [PATCH 0/5] Implement port 92 in south bridges

2024-03-13 Thread Bernhard Beschow



Am 12. März 2024 15:47:21 UTC schrieb "Michael S. Tsirkin" :
>On Sun, Feb 18, 2024 at 02:16:56PM +0100, Bernhard Beschow wrote:
>> This series attempts to make QEMU's south bridge families PIIX, ICH9, and VIA
>> 82xx more self-contained by integrating IO port 92 like the originals do.
>
>Bernhard my understanding is that you agreed with Mark this
>needs more work. Dropping for now.

Yeah, no 9.0 material.

Best regards,
Bernhard



Re: [PATCH v3] docs/system/ppc: Document running Linux on AmigaNG machines

2024-03-12 Thread Bernhard Beschow



Am 12. März 2024 14:34:47 UTC schrieb Nicholas Piggin :
>On Tue Mar 12, 2024 at 8:36 PM AEST, Nicholas Piggin wrote:
>> On Tue Mar 12, 2024 at 7:28 PM AEST, Bernhard Beschow wrote:
>> >
>> >
>> > Am 9. März 2024 11:34:56 UTC schrieb BALATON Zoltan :
>> > >On Thu, 29 Feb 2024, BALATON Zoltan wrote:
>> > >> On Wed, 21 Feb 2024, BALATON Zoltan wrote:
>> > >>> Documentation on how to run Linux on the amigaone, pegasos2 and
>> > >>> sam460ex machines is currently buried in the depths of the qemu-devel
>> > >>> mailing list and in the source code. Let's collect the information in
>> > >>> the QEMU handbook for a one stop solution.
>> > >> 
>> > >> Ping? (Just so it's not missed from next pull.)
>> > >
>> > >Ping for freeze.
>> >
>> > Has this patch been tagged yet? It would really be a pity if it didn't 
>> > make it into 9.0.
>>
>> Will send out a PR today and I'll include it.
>>
>> >
>> > FWIW:
>> >
>> > Reviewed-by: Bernhard Beschow 
>>
>> Thanks, always helpful.
>
>Oh you are Co-author. Sorry, took some time for light bulb
>to turn on... In that case it needs your SOB to merge.
>
>I will have to leave it out of the PR if I don't get that in
>time, but we should be able to get a doc improvement past
>the soft freeze. It's essentially a usability bug-fix.
>
>Thanks,
>Nick
>
>>
>> Thanks,
>> Nick
>>
>> >
>> > >
>> > >> Regards,
>> > >> BALATON Zoltan
>> > >> 
>> > >>> Co-authored-by: Bernhard Beschow 
>> > >>> Signed-off-by: BALATON Zoltan 
>> > >>> Reviewed-by: Nicholas Piggin 
>> > >>> Tested-by: Bernhard Beschow 

In case it helps:

Signed-off-by: Bernhard Beschow 

>
>[...]
>



Re: [PULL 00/38] ppc-for-9.0-2 queue

2024-03-12 Thread Bernhard Beschow



Am 12. März 2024 16:58:11 UTC schrieb Nicholas Piggin :
>The following changes since commit 35ac6831d98e18e2c78c85c93e3a6ca1f1ae3e58:
>
>  Merge tag 'net-pull-request' of https://github.com/jasowang/qemu into 
> staging (2024-03-12 13:42:57 +)
>
>are available in the Git repository at:
>
>  https://gitlab.com/npiggin/qemu.git tags/pull-ppc-for-9.0-2-20240313
>
>for you to fetch changes up to e1617b845104032f0aaad9b91dcda56c7c437998:
>
>  spapr: nested: Introduce cap-nested-papr for Nested PAPR API (2024-03-13 
> 02:47:04 +1000)
>
>
>* PAPR nested hypervisor host implementation for spapr TCG
>* excp_helper.c code cleanups and improvements
>* Move more ops to decodetree
>* Deprecate pseries-2.12 machines and P9 and P10 DD1.0 CPUs
>* Document running Linux on AmigaNG
>* Update dt feature advertising POWER CPUs.
>* Add P10 PMU SPRs
>* Improve pnv topology calculation for SMT8 CPUs.
>* Various bug fixes.
>
>
>BALATON Zoltan (8):
>  docs/system/ppc: Document running Linux on AmigaNG machines

Thanks, Nicholas!

Best regards,
Bernhard

>  target/ppc: Use env_cpu for cpu_abort in excp_helper
>  target/ppc: Readability improvements in exception handlers
>  target/ppc: Add gen_exception_err_nip() function
>  target/ppc: Clean up ifdefs in excp_helper.c, part 1
>  target/ppc: Clean up ifdefs in excp_helper.c, part 2
>  target/ppc: Clean up ifdefs in excp_helper.c, part 3
>  target/ppc: Remove interrupt handler wrapper functions
>
>Benjamin Gray (1):
>  ppc/spapr: Add pa-features for POWER10 machines
>
>Caleb Schlossin (1):
>  ppc/pnv: Improve pervasive topology calculation for big-core
>
>Chinmay Rath (1):
>  target/ppc: Move add and subf type fixed-point arithmetic instructions 
> to decodetree
>
>Cédric Le Goater (1):
>  MAINTAINERS: Remove myself as reviewer from PPC
>
>Harsh Prateek Bora (14):
>  spapr: nested: register nested-hv api hcalls only for cap-nested-hv
>  spapr: nested: move nested part of spapr_get_pate into spapr_nested.c
>  spapr: nested: Introduce SpaprMachineStateNested to store related info.
>  spapr: nested: keep nested-hv related code restricted to its API.
>  spapr: nested: Document Nested PAPR API
>  spapr: nested: Introduce H_GUEST_[GET|SET]_CAPABILITIES hcalls.
>  spapr: nested: Introduce H_GUEST_[CREATE|DELETE] hcalls.
>  spapr: nested: Introduce H_GUEST_CREATE_VCPU hcall.
>  spapr: nested: Extend nested_ppc_state for nested PAPR API
>  spapr: nested: Initialize the GSB elements lookup table.
>  spapr: nested: Introduce H_GUEST_[GET|SET]_STATE hcalls.
>  spapr: nested: Use correct source for parttbl info for nested PAPR API.
>  spapr: nested: Introduce H_GUEST_RUN_VCPU hcall.
>  spapr: nested: Introduce cap-nested-papr for Nested PAPR API
>
>Madhavan Srinivasan (1):
>  target/ppc: Add power10 pmu SPRs
>
>Nicholas Piggin (10):
>  target/ppc: Fix GDB SPR regnum indexing
>  target/ppc: Prevent supervisor from modifying MSR[ME]
>  spapr: set MSR[ME] and MSR[FP] on client entry
>  ppc: Drop support for POWER9 and POWER10 DD1 chips
>  target/ppc: POWER10 does not have transactional memory
>  ppc/spapr|pnv: Remove SAO from pa-features
>  ppc/spapr: Remove copy-paste from pa-features
>  ppc/spapr: Adjust ibm,pa-features for POWER9
>  ppc/pnv: Permit ibm,pa-features set per machine variant
>  ppc/pnv: Set POWER9, POWER10 ibm,pa-features bits
>
>Philippe Mathieu-Daudé (1):
>  docs: Deprecate the pseries-2.12 machines
>
> MAINTAINERS|4 +-
> docs/about/deprecated.rst  |6 +-
> docs/devel/nested-papr.txt |  119 +++
> docs/system/ppc/amigang.rst|  161 +++
> docs/system/target-ppc.rst |1 +
> hw/ppc/pnv.c   |  175 +++-
> hw/ppc/pnv_core.c  |8 +-
> hw/ppc/ppc.c   |   10 +
> hw/ppc/spapr.c |   98 +-
> hw/ppc/spapr_caps.c|   54 +
> hw/ppc/spapr_cpu_core.c|8 +-
> hw/ppc/spapr_hcall.c   |   24 +-
> hw/ppc/spapr_nested.c  | 1556 +++-
> include/hw/ppc/pnv_chip.h  |2 +-
> include/hw/ppc/pnv_core.h  |1 +
> include/hw/ppc/spapr.h |   27 +-
> include/hw/ppc/spapr_nested.h  |  427 +++-
> target/ppc/cpu-models.c|4 -
> target/ppc/cpu.h   |   11 +
> target/ppc/cpu_init.c  |   46 +-
> target/ppc/excp_helper.c   |  418 +++-
> target/ppc/gdbstub.c   |7 +-
> target/ppc/helper_regs.c   |5 +
> 

Re: [PATCH v3] docs/system/ppc: Document running Linux on AmigaNG machines

2024-03-12 Thread Bernhard Beschow



Am 9. März 2024 11:34:56 UTC schrieb BALATON Zoltan :
>On Thu, 29 Feb 2024, BALATON Zoltan wrote:
>> On Wed, 21 Feb 2024, BALATON Zoltan wrote:
>>> Documentation on how to run Linux on the amigaone, pegasos2 and
>>> sam460ex machines is currently buried in the depths of the qemu-devel
>>> mailing list and in the source code. Let's collect the information in
>>> the QEMU handbook for a one stop solution.
>> 
>> Ping? (Just so it's not missed from next pull.)
>
>Ping for freeze.

Has this patch been tagged yet? It would really be a pity if it didn't make it 
into 9.0.

FWIW:

Reviewed-by: Bernhard Beschow 

>
>> Regards,
>> BALATON Zoltan
>> 
>>> Co-authored-by: Bernhard Beschow 
>>> Signed-off-by: BALATON Zoltan 
>>> Reviewed-by: Nicholas Piggin 
>>> Tested-by: Bernhard Beschow 
>>> ---
>>> v3: Apply changes and Tested-by tag from Bernhard
>>> v2: Move top level title one level up so subsections will be below it in TOC
>>> 
>>> MAINTAINERS |   1 +
>>> docs/system/ppc/amigang.rst | 161 
>>> docs/system/target-ppc.rst  |   1 +
>>> 3 files changed, 163 insertions(+)
>>> create mode 100644 docs/system/ppc/amigang.rst
>>> 
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 7d61fb9319..0aef8cb2a6 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -1562,6 +1562,7 @@ F: hw/rtc/m41t80.c
>>> F: pc-bios/canyonlands.dt[sb]
>>> F: pc-bios/u-boot-sam460ex-20100605.bin
>>> F: roms/u-boot-sam460ex
>>> +F: docs/system/ppc/amigang.rst
>>> 
>>> pegasos2
>>> M: BALATON Zoltan 
>>> diff --git a/docs/system/ppc/amigang.rst b/docs/system/ppc/amigang.rst
>>> new file mode 100644
>>> index 00..ba1a3d80b9
>>> --- /dev/null
>>> +++ b/docs/system/ppc/amigang.rst
>>> @@ -0,0 +1,161 @@
>>> +=
>>> +AmigaNG boards (``amigaone``, ``pegasos2``, ``sam460ex``)
>>> +=
>>> +
>>> +These PowerPC machines emulate boards that are primarily used for
>>> +running Amiga like OSes (AmigaOS 4, MorphOS and AROS) but these can
>>> +also run Linux which is what this section documents.
>>> +
>>> +Eyetech AmigaOne/Mai Logic Teron (``amigaone``)
>>> +===
>>> +
>>> +The ``amigaone`` machine emulates an AmigaOne XE mainboard by Eyetech
>>> +which is a rebranded Mai Logic Teron board with modified U-Boot
>>> +firmware to support AmigaOS 4.
>>> +
>>> +Emulated devices
>>> +
>>> +
>>> + * PowerPC 7457 CPU (can also use``-cpu g3, 750cxe, 750fx`` or ``750gx``)
>>> + * Articia S north bridge
>>> + * VIA VT82C686B south bridge
>>> + * PCI VGA compatible card (guests may need other card instead)
>>> + * PS/2 keyboard and mouse
>>> +
>>> +Firmware
>>> +
>>> +
>>> +A firmware binary is necessary for the boot process. It is a modified
>>> +U-Boot under GPL but its source is lost so it cannot be included in
>>> +QEMU. A binary is available at
>>> +https://www.hyperion-entertainment.com/index.php/downloads?view=files=28.
>>> +The ROM image is in the last 512kB which can be extracted with the
>>> +following command:
>>> +
>>> +.. code-block:: bash
>>> +
>>> +  $ tail -c 524288 updater.image > u-boot-amigaone.bin
>>> +
>>> +The BIOS emulator in the firmware is unable to run QEMU‘s standard
>>> +vgabios so ``VGABIOS-lgpl-latest.bin`` is needed instead which can be
>>> +downloaded from http://www.nongnu.org/vgabios.
>>> +
>>> +Running Linux
>>> +-
>>> +
>>> +There are some Linux images under the following link that work on the
>>> +``amigaone`` machine:
>>> +https://sourceforge.net/projects/amigaone-linux/files/debian-installer/.
>>> +To boot the system run:
>>> +
>>> +.. code-block:: bash
>>> +
>>> +  $ qemu-system-ppc -machine amigaone -bios u-boot-amigaone.bin \
>>> +-cdrom "A1 Linux Net Installer.iso" \
>>> +-device 
>>> ati-vga,model=rv100,romfile=VGABIOS-lgpl-latest.bin
>>> +
>>> +From the firmware menu that appears select ``Boot sequence`` →
>>> +``Amiga Multiboot Options

Re: [PATCH 1/2] hw/pci-host/pam: Free PAMMemoryRegion from Intel-specific bit handling

2024-03-09 Thread Bernhard Beschow



Am 9. März 2024 16:29:23 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Hi Bernhard,
>
>On 9/3/24 14:40, Bernhard Beschow wrote:
>> The PAM bit extraction is currently spread across pam.c and the northbridge
>> device models, making the extraction logic harder to comprehend. Also note 
>> how
>> pam_update() deals with PAM_REGIONS_COUNT, even though it handles exactly one
>> region. Fix this (at the cost of minor code duplication) by moving the bit
>> extraction into the northbridge device models. As a side effect, pam_update()
>> becomes less Intel-specific which would allow it to be reused e.g. in VIA
>> northbridges.
>> 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   include/hw/pci-host/pam.h |  7 +++
>>   hw/pci-host/i440fx.c  |  7 +--
>>   hw/pci-host/pam.c | 14 +++---
>>   hw/pci-host/q35.c |  5 +++--
>>   4 files changed, 18 insertions(+), 15 deletions(-)
>> 
>> diff --git a/include/hw/pci-host/pam.h b/include/hw/pci-host/pam.h
>> index 005916f826..b9b33aecc8 100644
>> --- a/include/hw/pci-host/pam.h
>> +++ b/include/hw/pci-host/pam.h
>> @@ -70,7 +70,6 @@
>>   /* PAM registers: log nibble and high nibble*/
>>   #define PAM_ATTR_WE ((uint8_t)2)
>>   #define PAM_ATTR_RE ((uint8_t)1)
>> -#define PAM_ATTR_MASK   ((uint8_t)3)
>
>Why not use PAM_ATTR_foo instead of MCH_HOST_BRIDGE_PAM_foo?

Could be used indeed. See also below.

>
>>   /* SMRAM register */
>>   #define SMRAM_D_OPEN   ((uint8_t)(1 << 6))
>> @@ -83,13 +82,13 @@
>>   #define PAM_REGIONS_COUNT   13
>> typedef struct PAMMemoryRegion {
>> -MemoryRegion alias[4];  /* index = PAM value */
>> -unsigned current;
>> +MemoryRegion alias[4];  /* index = mode value */
>> +uint8_t mode;
>>   } PAMMemoryRegion;
>> void init_pam(PAMMemoryRegion *mem, Object *owner, MemoryRegion *ram,
>> MemoryRegion *system, MemoryRegion *pci,
>> uint32_t start, uint32_t size);
>> -void pam_update(PAMMemoryRegion *mem, int idx, uint8_t val);
>> +void pam_update(PAMMemoryRegion *mem, uint8_t mode);
>> #endif /* QEMU_PAM_H */
>> diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
>> index 4f0a0438d7..cddd506ab0 100644
>> --- a/hw/pci-host/i440fx.c
>> +++ b/hw/pci-host/i440fx.c
>> @@ -64,6 +64,8 @@ struct I440FXState {
>>   #define I440FX_PAM_SIZE 7
>>   #define I440FX_SMRAM0x72
>>   +#define I440FX_PAM_ATTR_MASK ((uint8_t)3)
>
>or (PAM_ATTR_RE|PAM_ATTR_WE)?
>
>It is odd to have I440FX_PAM_ATTR_MASK disconnected
>from the values it masks.

PAM_ATTR_RE and PAM_ATTR_WE are swapped in case of VIA. I didn't bother about 
these constants since both are currently not used at all. Shall I remove them 
in case of a respin?

>
>> -void pam_update(PAMMemoryRegion *pam, int idx, uint8_t val)
>> +void pam_update(PAMMemoryRegion *pam, uint8_t mode)
>>   {
>> -assert(0 <= idx && idx < PAM_REGIONS_COUNT);
>> +g_assert(mode < ARRAY_SIZE(pam->alias));
>>   -memory_region_set_enabled(>alias[pam->current], false);
>> -pam->current = (val >> ((!(idx & 1)) * 4)) & PAM_ATTR_MASK;
>
>Can we pass the mask by argument instead?

For VIA, each PAM region is defined by just two bits (rather than four as for 
Intel). So a byte contains attributes for four regions instead of two. 
Therefore, passing a mask alone doesn't help, one needed to pass a shift value 
as well. Furthermore, since PAM_ATTR_RE and PAM_ATTR_WE are swapped, it seems 
cleaner to just pass the final mode value.

Do we consider avoiding the redundancies more worthwhile than having the bit 
extraction logic together? If so, I'm fine with dropping the series until a VIA 
northbridge gets accepted. Perhaps what's missing is a bit extraction API which 
spans multiple bytes. Please let me know.

>
>> -memory_region_set_enabled(>alias[pam->current], true);
>> +memory_region_set_enabled(>alias[pam->mode], false);
>> +pam->mode = mode;
>> +memory_region_set_enabled(>alias[pam->mode], true);
>>   }
>
>Are the VIA values different of the PAM_ATTR_foo ones?

They are different except for PAM_ATTR_MASK.

>
>I'm not sure this is an helpful change, I'd rather
>remove the MCH_HOST_BRIDGE_PAM_foo definitions and
>use the PAM generic ones.

PAM_ATTR_MASK could indeed be reused for VIA. I'd respin if this series made 
sense in its own right.

Best regsrds,
Bernhard

>
>Regards,
>
>Phil.



[PATCH 1/2] hw/pci-host/pam: Free PAMMemoryRegion from Intel-specific bit handling

2024-03-09 Thread Bernhard Beschow
The PAM bit extraction is currently spread across pam.c and the northbridge
device models, making the extraction logic harder to comprehend. Also note how
pam_update() deals with PAM_REGIONS_COUNT, even though it handles exactly one
region. Fix this (at the cost of minor code duplication) by moving the bit
extraction into the northbridge device models. As a side effect, pam_update()
becomes less Intel-specific which would allow it to be reused e.g. in VIA
northbridges.

Signed-off-by: Bernhard Beschow 
---
 include/hw/pci-host/pam.h |  7 +++
 hw/pci-host/i440fx.c  |  7 +--
 hw/pci-host/pam.c | 14 +++---
 hw/pci-host/q35.c |  5 +++--
 4 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/include/hw/pci-host/pam.h b/include/hw/pci-host/pam.h
index 005916f826..b9b33aecc8 100644
--- a/include/hw/pci-host/pam.h
+++ b/include/hw/pci-host/pam.h
@@ -70,7 +70,6 @@
 /* PAM registers: log nibble and high nibble*/
 #define PAM_ATTR_WE ((uint8_t)2)
 #define PAM_ATTR_RE ((uint8_t)1)
-#define PAM_ATTR_MASK   ((uint8_t)3)
 
 /* SMRAM register */
 #define SMRAM_D_OPEN   ((uint8_t)(1 << 6))
@@ -83,13 +82,13 @@
 #define PAM_REGIONS_COUNT   13
 
 typedef struct PAMMemoryRegion {
-MemoryRegion alias[4];  /* index = PAM value */
-unsigned current;
+MemoryRegion alias[4];  /* index = mode value */
+uint8_t mode;
 } PAMMemoryRegion;
 
 void init_pam(PAMMemoryRegion *mem, Object *owner, MemoryRegion *ram,
   MemoryRegion *system, MemoryRegion *pci,
   uint32_t start, uint32_t size);
-void pam_update(PAMMemoryRegion *mem, int idx, uint8_t val);
+void pam_update(PAMMemoryRegion *mem, uint8_t mode);
 
 #endif /* QEMU_PAM_H */
diff --git a/hw/pci-host/i440fx.c b/hw/pci-host/i440fx.c
index 4f0a0438d7..cddd506ab0 100644
--- a/hw/pci-host/i440fx.c
+++ b/hw/pci-host/i440fx.c
@@ -64,6 +64,8 @@ struct I440FXState {
 #define I440FX_PAM_SIZE 7
 #define I440FX_SMRAM0x72
 
+#define I440FX_PAM_ATTR_MASK ((uint8_t)3)
+
 /* Keep it 2G to comply with older win32 guests */
 #define I440FX_PCI_HOST_HOLE64_SIZE_DEFAULT (1ULL << 31)
 
@@ -88,8 +90,9 @@ static void i440fx_update_memory_mappings(PCII440FXState *d)
 
 memory_region_transaction_begin();
 for (i = 0; i < ARRAY_SIZE(d->pam_regions); i++) {
-pam_update(>pam_regions[i], i,
-   pd->config[I440FX_PAM + DIV_ROUND_UP(i, 2)]);
+uint8_t reg = pd->config[I440FX_PAM + DIV_ROUND_UP(i, 2)];
+pam_update(>pam_regions[i],
+   (reg >> ((!(i & 1)) * 4)) & I440FX_PAM_ATTR_MASK);
 }
 memory_region_set_enabled(>smram_region,
   !(pd->config[I440FX_SMRAM] & SMRAM_D_OPEN));
diff --git a/hw/pci-host/pam.c b/hw/pci-host/pam.c
index 68e9884d27..29c0db097a 100644
--- a/hw/pci-host/pam.c
+++ b/hw/pci-host/pam.c
@@ -51,20 +51,20 @@ void init_pam(PAMMemoryRegion *mem, Object *owner, 
MemoryRegion *ram_memory,
  start, size);
 
 memory_region_transaction_begin();
-for (i = 0; i < 4; ++i) {
+for (i = 0; i < ARRAY_SIZE(mem->alias); ++i) {
 memory_region_set_enabled(>alias[i], false);
 memory_region_add_subregion_overlap(system_memory, start,
 >alias[i], 1);
 }
 memory_region_transaction_commit();
-mem->current = 0;
+mem->mode = 0;
 }
 
-void pam_update(PAMMemoryRegion *pam, int idx, uint8_t val)
+void pam_update(PAMMemoryRegion *pam, uint8_t mode)
 {
-assert(0 <= idx && idx < PAM_REGIONS_COUNT);
+g_assert(mode < ARRAY_SIZE(pam->alias));
 
-memory_region_set_enabled(>alias[pam->current], false);
-pam->current = (val >> ((!(idx & 1)) * 4)) & PAM_ATTR_MASK;
-memory_region_set_enabled(>alias[pam->current], true);
+memory_region_set_enabled(>alias[pam->mode], false);
+pam->mode = mode;
+memory_region_set_enabled(>alias[pam->mode], true);
 }
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 0d7d4e3f08..947d9aa9c4 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -330,8 +330,9 @@ static void mch_update_pam(MCHPCIState *mch)
 
 memory_region_transaction_begin();
 for (i = 0; i < 13; i++) {
-pam_update(>pam_regions[i], i,
-   pd->config[MCH_HOST_BRIDGE_PAM0 + DIV_ROUND_UP(i, 2)]);
+uint8_t reg = pd->config[MCH_HOST_BRIDGE_PAM0 + DIV_ROUND_UP(i, 2)];
+pam_update(>pam_regions[i],
+   (reg >> ((!(i & 1)) * 4)) & MCH_HOST_BRIDGE_PAM_MASK);
 }
 memory_region_transaction_commit();
 }
-- 
2.44.0




[PATCH 2/2] hw/pci-host/pam: Remove northbridge-specific PAM_REGIONS_COUNT

2024-03-09 Thread Bernhard Beschow
PAM_REGIONS_COUNT being 13 seems to be Intel-specific. There are VIA 82cXX
northbridges having only 10, for example. Communicate this by having
northbridge-specific constants.

Signed-off-by: Bernhard Beschow 

--

Do we need the constants or can we omit them, given they're just used once?
---
 include/hw/pci-host/i440fx.h | 4 +++-
 include/hw/pci-host/pam.h| 2 --
 include/hw/pci-host/q35.h| 4 +++-
 hw/pci-host/q35.c| 2 +-
 4 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/include/hw/pci-host/i440fx.h b/include/hw/pci-host/i440fx.h
index c988f70890..9e9b252660 100644
--- a/include/hw/pci-host/i440fx.h
+++ b/include/hw/pci-host/i440fx.h
@@ -22,12 +22,14 @@
 
 OBJECT_DECLARE_SIMPLE_TYPE(PCII440FXState, I440FX_PCI_DEVICE)
 
+#define I440FX_HOST_PAM_REGIONS_COUNT 13
+
 struct PCII440FXState {
 /*< private >*/
 PCIDevice parent_obj;
 /*< public >*/
 
-PAMMemoryRegion pam_regions[PAM_REGIONS_COUNT];
+PAMMemoryRegion pam_regions[I440FX_HOST_PAM_REGIONS_COUNT];
 MemoryRegion smram_region;
 MemoryRegion smram, low_smram;
 };
diff --git a/include/hw/pci-host/pam.h b/include/hw/pci-host/pam.h
index b9b33aecc8..25dbe6feaf 100644
--- a/include/hw/pci-host/pam.h
+++ b/include/hw/pci-host/pam.h
@@ -79,8 +79,6 @@
 #define SMRAM_C_BASE_SEG_MASK  ((uint8_t)0x7)
 #define SMRAM_C_BASE_SEG   ((uint8_t)0x2)  /* hardwired to b010 */
 
-#define PAM_REGIONS_COUNT   13
-
 typedef struct PAMMemoryRegion {
 MemoryRegion alias[4];  /* index = mode value */
 uint8_t mode;
diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index bafcbe6752..618ecf05f4 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -35,6 +35,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(Q35PCIHost, Q35_HOST_DEVICE)
 #define TYPE_MCH_PCI_DEVICE "mch"
 OBJECT_DECLARE_SIMPLE_TYPE(MCHPCIState, MCH_PCI_DEVICE)
 
+#define MCH_HOST_PAM_REGIONS_COUNT 13
+
 struct MCHPCIState {
 /*< private >*/
 PCIDevice parent_obj;
@@ -44,7 +46,7 @@ struct MCHPCIState {
 MemoryRegion *pci_address_space;
 MemoryRegion *system_memory;
 MemoryRegion *address_space_io;
-PAMMemoryRegion pam_regions[PAM_REGIONS_COUNT];
+PAMMemoryRegion pam_regions[MCH_HOST_PAM_REGIONS_COUNT];
 MemoryRegion smram_region, open_high_smram;
 MemoryRegion smram, low_smram, high_smram;
 MemoryRegion tseg_blackhole, tseg_window;
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 947d9aa9c4..6782bf4216 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -329,7 +329,7 @@ static void mch_update_pam(MCHPCIState *mch)
 int i;
 
 memory_region_transaction_begin();
-for (i = 0; i < 13; i++) {
+for (i = 0; i < ARRAY_SIZE(mch->pam_regions); i++) {
 uint8_t reg = pd->config[MCH_HOST_BRIDGE_PAM0 + DIV_ROUND_UP(i, 2)];
 pam_update(>pam_regions[i],
(reg >> ((!(i & 1)) * 4)) & MCH_HOST_BRIDGE_PAM_MASK);
-- 
2.44.0




[PATCH 0/2] Make PAMMemoryRegion less Intel-specific

2024-03-09 Thread Bernhard Beschow
This series makes pam_update() more self-contained by removing some Intel
assumptions. As a result, the purpose of PAMMemoryRegion becomes clearer and, as
a side effect, makes it reusable for northbridges other than Intel, e.g. VIA.

Testing done:
* `make check`
* `make check-avocado`
* This series is sent from a VM implementing this series.

Bernhard Beschow (2):
  hw/pci-host/pam: Free PAMMemoryRegion from Intel-specific bit handling
  hw/pci-host/pam: Remove northbridge-specific PAM_REGIONS_COUNT

 include/hw/pci-host/i440fx.h |  4 +++-
 include/hw/pci-host/pam.h|  9 +++--
 include/hw/pci-host/q35.h|  4 +++-
 hw/pci-host/i440fx.c |  7 +--
 hw/pci-host/pam.c| 14 +++---
 hw/pci-host/q35.c|  7 ---
 6 files changed, 25 insertions(+), 20 deletions(-)

-- 
2.44.0




Re: [RFC PATCH 4/5] hw/i386/q35: Wire virtual SMI# lines to ICH9 chipset

2024-03-08 Thread Bernhard Beschow



Am 8. März 2024 08:10:24 UTC schrieb Laszlo Ersek :
>On 3/8/24 09:08, Philippe Mathieu-Daudé wrote:
>> On 7/3/24 20:43, Thomas Huth wrote:
>>> On 28/02/2024 17.43, Zhao Liu wrote:
 Hi Philippe,

> +/*
> + * Real ICH9 contains a single SMI output line and doesn't
> broadcast CPUs.
> + * Virtualized ICH9 allows broadcasting upon negatiation with
> guest, see
> + * commit 5ce45c7a2b.
> + */
> +enum {
> +    ICH9_VIRT_SMI_BROADCAST,
> +    ICH9_VIRT_SMI_CURRENT,
> +#define ICH9_VIRT_SMI_COUNT 2
> +};
> +

 Just quick look here. Shouldn't ICH9_VIRT_SMI_COUNT be defined
 outside of
 enum {}?
>>>
>>> Or even better, do it without a #define:
>>>
>>> enum {
>>>  ICH9_VIRT_SMI_BROADCAST,
>>>  ICH9_VIRT_SMI_CURRENT,
>>>  ICH9_VIRT_SMI_COUNT
>> 
>> This form isn't recommended as it confuses static analyzers,
>> considering ICH9_VIRT_SMI_COUNT as part of the enum.
>
>Side comment: I didn't know about this (so thanks for the info), but
>that's really a shame for those static analyzers. It's an ancient and
>valid pattern. :/

Another pattern would be:

enum {
ICH9_VIRT_SMI_BROADCAST,
ICH9_VIRT_SMI_CURRENT,
ICH9_VIRT_SMI_LAST = ICH9_VIRT_SMI_CURRENT
};

which should also work with GCC's `-Wswitch-enum`.

Best regards,
Bernhard

>
>> 
>>> };
>>>
>>>   Thomas
>>>
>> 
>



Re: [PATCH 0/4] hw/i386/pc: Trivial cleanups

2024-03-07 Thread Bernhard Beschow



Am 1. März 2024 18:59:32 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Trivial cleanups, mostly around the 'isapc' machine.
>
>Philippe Mathieu-Daudé (4):
>  hw/i386/pc: Remove pc_compat_1_4..1.7[] left over declarations
>  hw/i386/pc: Use generated NotifyVmexitOption_str()
>  hw/i386/pc: Remove 'host_type' argument from pc_init1()
>  hw/i386/pc: Have pc_init_isa() pass a NULL pci_type argument

Ping. Will this series make it into 9.0? AFAICS all patches are reviewed.

>
> include/hw/i386/pc.h | 12 
> hw/i386/pc_piix.c| 18 ++
> 2 files changed, 6 insertions(+), 24 deletions(-)
>



Re: [PATCH v3 1/4] hw/i386/pc: Remove "rtc_state" link again

2024-03-05 Thread Bernhard Beschow



Am 5. März 2024 15:57:08 UTC schrieb Peter Maydell :
>On Sun, 3 Mar 2024 at 18:55, Bernhard Beschow  wrote:
>>
>> Commit 99e1c1137b6f "hw/i386/pc: Populate RTC attribute directly" made 
>> linking
>> the "rtc_state" property unnecessary and removed it. Commit 84e945aad2d0 "vl,
>> pc: turn -no-fd-bootchk into a machine property" accidently reintroduced the
>> link. Remove it again since it is not needed.
>>
>> Fixes: 84e945aad2d0 "vl, pc: turn -no-fd-bootchk into a machine property"
>> Cc: Paolo Bonzini 
>> Signed-off-by: Bernhard Beschow 
>
>Ah, I did wonder when I was working with this code whether that
>rtc_state link was really necessary.
>
>We could now remove the rtc argument from the pc_cmos_init()
>function, because we can guarantee that it's in x86ms->rtc,
>which the function already has access to from its pcms argument.

This series goes one step further and inlines this function. It would be a nice 
to get some feedback before the freeze.

Best regards,
Bernhard

>
>thanks
>-- PMM



[PATCH v3 4/4] hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove it

2024-03-03 Thread Bernhard Beschow
Now that pc_cmos_init() doesn't populate the X86MachineState::rtc attribute any
longer, its duties can be merged into pc_cmos_init_late() which is called within
machine_done notifier. This frees pc_piix and pc_q35 from explicit CMOS
initialization.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h |  2 --
 hw/i386/pc.c | 10 --
 hw/i386/pc_piix.c|  2 --
 hw/i386/pc_q35.c |  2 --
 4 files changed, 16 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 5065590281..bfdcd64514 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -178,8 +178,6 @@ void pc_basic_device_init(struct PCMachineState *pcms,
   ISADevice *rtc_state,
   bool create_fdctrl,
   uint32_t hpet_irqs);
-void pc_cmos_init(PCMachineState *pcms,
-  ISADevice *s);
 void pc_nic_init(PCMachineClass *pcmc, ISABus *isa_bus, PCIBus *pci_bus);
 
 void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7780d8d6dd..69e134e141 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -570,14 +570,6 @@ static void pc_cmos_init_late(PCMachineState *pcms)
 mc146818rtc_set_cmos_data(s, 0x39, val);
 
 pc_cmos_init_floppy(s, pc_find_fdc0());
-}
-
-void pc_cmos_init(PCMachineState *pcms,
-  ISADevice *rtc)
-{
-int val;
-X86MachineState *x86ms = X86_MACHINE(pcms);
-MC146818RtcState *s = MC146818_RTC(rtc);
 
 /* various important CMOS locations needed by PC/Bochs bios */
 
@@ -618,8 +610,6 @@ void pc_cmos_init(PCMachineState *pcms,
 val |= 0x02; /* FPU is there */
 val |= 0x04; /* PS/2 mouse installed */
 mc146818rtc_set_cmos_data(s, REG_EQUIPMENT_BYTE, val);
-
-/* hard drives and FDC are handled by pc_cmos_init_late() */
 }
 
 static void handle_a20_line_change(void *opaque, int irq, int level)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ce6aad758d..637f4d38be 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -342,8 +342,6 @@ static void pc_init1(MachineState *machine,
 }
 #endif
 
-pc_cmos_init(pcms, x86ms->rtc);
-
 if (piix4_pm) {
 smi_irq = qemu_allocate_irq(pc_acpi_smi_interrupt, first_cpu, 0);
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 45a4102e75..bccd13d162 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -311,8 +311,6 @@ static void pc_q35_init(MachineState *machine)
 smbus_eeprom_init(pcms->smbus, 8, NULL, 0);
 }
 
-pc_cmos_init(pcms, x86ms->rtc);
-
 /* the rest devices to which pci devfn is automatically assigned */
 pc_vga_init(isa_bus, pcms->pcibus);
 pc_nic_init(pcmc, isa_bus, pcms->pcibus);
-- 
2.44.0




[PATCH v3 0/4] Simplify initialization of PC machines

2024-03-03 Thread Bernhard Beschow
The series aims to simplify the initialization process of all PC-based machines
by streamlining redundant code.

Since I haven't seen patches on the list so far for folding CMOS data
generation into pc.c, which frees all PC machines from performing this duty
explicitly, I've appended this cleanup as the last two patches.

Testing done:
* `make check` -> all tests pass
* `make check-avocado`
* I'm sending this series from within a VM containing these changes.

v3:
* Rebase onto master
* Fix boot-order-test
* Remove the "rtc_state" link again which got accidently reintroduced
* Add patch avoiding one use of the current_machine global

v2:
* Rebase onto master, leaving only patches 1, 3, and 5
* Patch 2: Rename "bus" attribute to "pcibus" (Phil)
* Patch 4: Spotted while rebasing
* Patch 6: New patch possible after [1]

Best regards,
Bernhard

[1]
https://patchew.org/QEMU/20240221211626.48190-1-phi...@linaro.org/20240221211626
.48190-10-phi...@linaro.org/

Bernhard Beschow (4):
  hw/i386/pc: Remove "rtc_state" link again
  hw/i386/pc: Avoid one use of the current_machine global
  hw/i386/pc: Set "normal" boot device order in pc_basic_device_init()
  hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove
it

 include/hw/i386/pc.h |  2 --
 hw/i386/pc.c | 29 ++---
 hw/i386/pc_piix.c|  2 --
 hw/i386/pc_q35.c |  2 --
 4 files changed, 6 insertions(+), 29 deletions(-)

-- 
2.44.0




[PATCH v3 1/4] hw/i386/pc: Remove "rtc_state" link again

2024-03-03 Thread Bernhard Beschow
Commit 99e1c1137b6f "hw/i386/pc: Populate RTC attribute directly" made linking
the "rtc_state" property unnecessary and removed it. Commit 84e945aad2d0 "vl,
pc: turn -no-fd-bootchk into a machine property" accidently reintroduced the
link. Remove it again since it is not needed.

Fixes: 84e945aad2d0 "vl, pc: turn -no-fd-bootchk into a machine property"
Cc: Paolo Bonzini 
Signed-off-by: Bernhard Beschow 
---
 hw/i386/pc.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f5ff970acf..63b7583af0 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -613,14 +613,6 @@ void pc_cmos_init(PCMachineState *pcms,
 mc146818rtc_set_cmos_data(s, 0x5c, val >> 8);
 mc146818rtc_set_cmos_data(s, 0x5d, val >> 16);
 
-object_property_add_link(OBJECT(pcms), "rtc_state",
- TYPE_ISA_DEVICE,
- (Object **)>rtc,
- object_property_allow_set_link,
- OBJ_PROP_LINK_STRONG);
-object_property_set_link(OBJECT(pcms), "rtc_state", OBJECT(s),
- _abort);
-
 set_boot_dev(pcms, s, MACHINE(pcms)->boot_config.order, _fatal);
 
 val = 0;
-- 
2.44.0




[PATCH v3 3/4] hw/i386/pc: Set "normal" boot device order in pc_basic_device_init()

2024-03-03 Thread Bernhard Beschow
The boot device order may change during the lifetime of a VM. Usually, the
"normal" order is set once during machine init(). However, if a user specifies
`-boot once=...`, the "normal" order is overwritten by the "once" order just
before machine_done, and a reset handler is registered which restores the
"normal" order during the next reset.

In the next patch, pc_cmos_init() will be inlined into pc_cmos_init_late() which
runs during machine_done. This means that the "once" boot order would be
overwritten again with the "normal" boot order -- which renders the user's
choice ineffective. Fix this by setting the "normal" boot order in
pc_basic_device_init() which already registers the boot_set() handler.

Signed-off-by: Bernhard Beschow 
---
 hw/i386/pc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 06ef278b34..7780d8d6dd 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -614,8 +614,6 @@ void pc_cmos_init(PCMachineState *pcms,
 mc146818rtc_set_cmos_data(s, 0x5c, val >> 8);
 mc146818rtc_set_cmos_data(s, 0x5d, val >> 16);
 
-set_boot_dev(pcms, s, MACHINE(pcms)->boot_config.order, _fatal);
-
 val = 0;
 val |= 0x02; /* FPU is there */
 val |= 0x04; /* PS/2 mouse installed */
@@ -1254,6 +1252,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
 #endif
 
 qemu_register_boot_set(pc_boot_set, pcms);
+set_boot_dev(pcms, MC146818_RTC(rtc_state),
+ MACHINE(pcms)->boot_config.order, _fatal);
 
 if (!xen_enabled() &&
 (x86ms->pit == ON_OFF_AUTO_AUTO || x86ms->pit == ON_OFF_AUTO_ON)) {
-- 
2.44.0




[PATCH v3 2/4] hw/i386/pc: Avoid one use of the current_machine global

2024-03-03 Thread Bernhard Beschow
The RTC can be accessed through the X86 machine instance, so rather than passing
the RTC it's possible to pass the machine state instead. This avoids
pc_boot_set() from having to access the current_machine global.

Signed-off-by: Bernhard Beschow 
---
 hw/i386/pc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 63b7583af0..06ef278b34 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -425,9 +425,10 @@ static void set_boot_dev(PCMachineState *pcms, 
MC146818RtcState *s,
 
 static void pc_boot_set(void *opaque, const char *boot_device, Error **errp)
 {
-PCMachineState *pcms = PC_MACHINE(current_machine);
+PCMachineState *pcms = opaque;
+X86MachineState *x86ms = X86_MACHINE(pcms);
 
-set_boot_dev(pcms, opaque, boot_device, errp);
+set_boot_dev(pcms, MC146818_RTC(x86ms->rtc), boot_device, errp);
 }
 
 static void pc_cmos_init_floppy(MC146818RtcState *rtc_state, ISADevice *floppy)
@@ -1252,7 +1253,7 @@ void pc_basic_device_init(struct PCMachineState *pcms,
 }
 #endif
 
-qemu_register_boot_set(pc_boot_set, rtc_state);
+qemu_register_boot_set(pc_boot_set, pcms);
 
 if (!xen_enabled() &&
 (x86ms->pit == ON_OFF_AUTO_AUTO || x86ms->pit == ON_OFF_AUTO_ON)) {
-- 
2.44.0




Re: [PATCH v3 10/12] plugins: add range list API

2024-03-03 Thread Bernhard Beschow



Am 1. März 2024 17:46:07 UTC schrieb Sven Schnelle :
>Export range_list_from_string(), range_contains() and range_list_free()
>to allow plugins to parse filter ranges and match them to avoid
>reimplementing this functionality.
>
>Signed-off-by: Sven Schnelle 
>---
> include/qemu/qemu-plugin.h   | 41 
> plugins/api.c| 18 
> plugins/qemu-plugins.symbols |  3 +++
> 3 files changed, 62 insertions(+)
>
>diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
>index 5839feea4d..4910a63d70 100644
>--- a/include/qemu/qemu-plugin.h
>+++ b/include/qemu/qemu-plugin.h
>@@ -765,4 +765,45 @@ typedef struct Error Error;
> QEMU_PLUGIN_API
> void qemu_plugin_error_print(Error *err);
> 
>+typedef GList qemu_plugin_range_list;
>+
>+/**
>+ * qemu_plugin_ranges_from_string() - parse a filter range string
>+ *
>+ * @out_ranges: a pointer to a @qemu_plugin_range_list pointer
>+ * @filter_spec: input string
>+ * @errp: @Error string on parse failure
>+ *
>+ * This function parses a filter specification string and stores the
>+ * parsed adress ranges found in @out. On parse failure a @Error pointer
>+ * is stored in @errp. The function accepts a comma-separated list
>+ * of start and end addresses or single addresses.
>+ */
>+QEMU_PLUGIN_API
>+void qemu_plugin_range_list_from_string(qemu_plugin_range_list **out_range,

Nice series in general. One nitpick: When the API docs are generated I get the 
following error:

include/qemu/qemu-plugin.h:788: warning: Function parameter or member 
'out_range' not described in 'qemu_plugin_range_list_from_string'

This is due to the parameter being documented as "out_ranges" which seems like 
the more appropriate name given its type. It might also be cleaner to have the 
same names in the source, too.

Best regards,
Bernhard

>+const char *filter_spec,
>+Error **errp);
>+
>+/**
>+ * qemu_plugin_range_list_contains() - match a value against a list
>+ * of ranges
>+ *
>+ * @ranges: a pointer to a @qemu_plugin_range_list
>+ * @val: the value to match
>+ *
>+ * This function matches @val against the adress range list in @ranges.
>+ * On success, true is returned, otherwise false.
>+ */
>+QEMU_PLUGIN_API
>+bool qemu_plugin_range_list_contains(qemu_plugin_range_list *ranges,
>+ uint64_t val);
>+
>+/**
>+ * qemu_plugin_range_list_free() - free a list of ranges
>+ *
>+ * @ranges: a pointer to the list to be freed
>+ */
>+QEMU_PLUGIN_API
>+void qemu_plugin_range_list_free(qemu_plugin_range_list *ranges);
>+
> #endif /* QEMU_QEMU_PLUGIN_H */
>diff --git a/plugins/api.c b/plugins/api.c
>index 8fd3a8964a..8dbd14c648 100644
>--- a/plugins/api.c
>+++ b/plugins/api.c
>@@ -472,3 +472,21 @@ void qemu_plugin_error_print(Error *err)
> error_report_err(err);
> }
> 
>+void qemu_plugin_range_list_from_string(qemu_plugin_range_list **out,
>+const char *filter_spec,
>+Error **errp)
>+{
>+return range_list_from_string(out, filter_spec, errp);
>+}
>+
>+bool qemu_plugin_range_list_contains(qemu_plugin_range_list *ranges,
>+ uint64_t val)
>+{
>+return range_list_contains(ranges, val);
>+}
>+
>+void qemu_plugin_range_list_free(qemu_plugin_range_list *ranges)
>+{
>+return range_list_free(ranges);
>+}
>+
>diff --git a/plugins/qemu-plugins.symbols b/plugins/qemu-plugins.symbols
>index b142d11e58..472b29fc5f 100644
>--- a/plugins/qemu-plugins.symbols
>+++ b/plugins/qemu-plugins.symbols
>@@ -21,6 +21,9 @@
>   qemu_plugin_num_vcpus;
>   qemu_plugin_outs;
>   qemu_plugin_path_to_binary;
>+  qemu_plugin_range_list_contains;
>+  qemu_plugin_range_list_free;
>+  qemu_plugin_range_list_from_string;
>   qemu_plugin_read_register;
>   qemu_plugin_register_atexit_cb;
>   qemu_plugin_register_flush_cb;



Re: [PATCH 3/5] hw/isa: Embed TYPE_PORT92 in south bridges used in PC machines

2024-03-02 Thread Bernhard Beschow



Am 28. Februar 2024 13:02:55 UTC schrieb BALATON Zoltan :
>On Wed, 28 Feb 2024, BALATON Zoltan wrote:
>> On Tue, 27 Feb 2024, Bernhard Beschow wrote:
>>> Am 27. Februar 2024 21:54:19 UTC schrieb BALATON Zoltan 
>>> :
>>>> On Tue, 27 Feb 2024, Bernhard Beschow wrote:
>>>>> Am 21. Februar 2024 11:53:21 UTC schrieb Mark Cave-Ayland 
>>>>> :
>>>>>> On 18/02/2024 13:16, Bernhard Beschow wrote:
>>>>>>> Port 92 is an integral part of the PIIX and ICH south bridges, so 
>>>>>>> instantiate it
>>>>>>> there. The isapc machine now needs to instantiate it explicitly, 
>>>>>>> analoguous to
>>>>>>> the RTC.
>>>>>>> 
>>>>>>> Note that due to migration compatibility, port92 is optional in the 
>>>>>>> south
>>>>>>> bridges. It is always instantiated the isapc machine for simplicity.
>>>>>>> 
>>>>>>> Signed-off-by: Bernhard Beschow 
>>>>>>> ---
>>>>>>>   include/hw/i386/pc.h  |  2 +-
>>>>>>>   include/hw/southbridge/ich9.h |  4 
>>>>>>>   include/hw/southbridge/piix.h |  3 +++
>>>>>>>   hw/i386/pc.c  | 18 --
>>>>>>>   hw/i386/pc_piix.c |  9 +++--
>>>>>>>   hw/i386/pc_q35.c  |  8 +---
>>>>>>>   hw/isa/lpc_ich9.c |  9 +
>>>>>>>   hw/isa/piix.c |  9 +
>>>>>>>   hw/isa/Kconfig|  2 ++
>>>>>>>   9 files changed, 52 insertions(+), 12 deletions(-)
>>>>>> 
>>>>>> I had a look at this (and did a bit of revision around 8042 and A20), 
>>>>>> and I am starting to wonder if the PORT92 device isn't something that 
>>>>>> belongs to the southbridge, but more specifically to the superio chip?
>>>>> 
>>>>> If there is agreement to model real hardware in QEMU, then I think that
>>>> 
>>>> I think there's no such agreement and QEMU is more lax about it both for 
>>>> historical reasons and to simplify machine models. Indeed, QEMU sometimes 
>>>> models non-existing machines (e.g. the mac99 or virt boards) that don't 
>>>> correspond to real hardware but allow guest OSes to boot. Even when 
>>>> modelllng real hardware it's ofren modelled just enough for guests to work 
>>>> and unused details are omitted for simplicity. It is recommended to follow 
>>>> what real hardware does when modelling real hardware but not always 
>>>> required. Although it might help both with verifying a device model and to 
>>>> compose machines with these models to try to follow the real hardware.
>>> 
>>> Composing real machines and verifying device models is exactly what I'm 
>>> after. I'm aware that QEMU provides virt machines such as the microvm, and 
>>> from the context I didn't refer to these.
>> 
>> Even without pure virt machines currently a lot of QEMU machines don't 
>> exactly model real hardware. They may roughly follow real hardware but not 
>> exactly such as mac99 is a non-existent Mac and the pc machines also use 
>> some parts that don't exist in real life such as PIIX4-PIIX3 hybrid you've 
>> been working on resolving. Some of these however are restricted by backward 
>> compatibilty requirements. But you probably aware of all of that but this 
>> means the argument that real hardware should be followed is not enough. At 
>> least it should not break backward compatibility too much and that's more 
>> important than exactly modelling real machine. Also having a simple model 
>> may be more important than modeling every detail even when not used just to 
>> follow real hardware.
>> 
>>>>> port 92 belongs into any device model where the hardware has one. All our 
>>>>> PC-like southbridges (PIIX, ICH, VIA) have port 92. Many FDC37 
>>>>> including the FDC37M81x as used in the Malta board have one, too -- where 
>>>>> it must first be enabled.
>>>> 
>>>> So port92 is not a real hardware but a QEMU abstraction or model of some 
>>>> functionality found in some machines. Real chips probably implement this 
>>>> in different ways so we could either model this in these chips 
>>>> independently the same way as real hardw

Re: [PATCH 4/4] hw/i386/pc: Have pc_init_isa() pass a NULL pci_type argument

2024-03-02 Thread Bernhard Beschow



Am 1. März 2024 18:59:36 UTC schrieb "Philippe Mathieu-Daudé" 
:
>The "isapc" machine only provides an ISA bus, not a PCI one,
>and doesn't instanciate any i440FX south bridge.
>Its machine class defines PCMachineClass::pci_enabled = false,
>and pc_init1() only uses the pci_type argument when pci_enabled
>is true. Since for this machine the argument is not used,
>passing NULL makes more sense.
>
>Signed-off-by: Philippe Mathieu-Daudé 

Reviewed-by: Bernhard Beschow 



Re: [PATCH 0/2] Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"

2024-02-29 Thread Bernhard Beschow



Am 26. Februar 2024 21:59:07 UTC schrieb Bernhard Beschow :
>As reported by Volker [1], commit 6f6ad2b24582 "hw/i386/pc: Confine system
>
>flash handling to pc_sysfw" causes a regression when specifying the property
>
>`-M pflash0` in the PCI PC machines:
>
>  qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found
>
>Revert the commit for now until a solution is found.
>

Ping

>
>
>Best regards,
>
>Bernhard
>
>
>
>[1] 
>https://lore.kernel.org/qemu-devel/9e82a04b-f2c1-4e34-b4b6-46a0581b5...@t-online.de/
>
>
>
>Bernhard Beschow (2):
>
>  Revert "hw/i386/pc_sysfw: Inline pc_system_flash_create() and remove
>
>it"
>
>  Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"
>
>
>
> include/hw/i386/pc.h |  2 ++
>
> hw/i386/pc.c |  1 +
>
> hw/i386/pc_piix.c|  1 +
>
> hw/i386/pc_sysfw.c   | 17 +
>
> 4 files changed, 17 insertions(+), 4 deletions(-)
>
>
>
>-- >
>2.44.0
>
>
>



Re: [PATCH 3/5] hw/isa: Embed TYPE_PORT92 in south bridges used in PC machines

2024-02-27 Thread Bernhard Beschow



Am 27. Februar 2024 21:54:19 UTC schrieb BALATON Zoltan :
>On Tue, 27 Feb 2024, Bernhard Beschow wrote:
>> Am 21. Februar 2024 11:53:21 UTC schrieb Mark Cave-Ayland 
>> :
>>> On 18/02/2024 13:16, Bernhard Beschow wrote:
>>>> Port 92 is an integral part of the PIIX and ICH south bridges, so 
>>>> instantiate it
>>>> there. The isapc machine now needs to instantiate it explicitly, 
>>>> analoguous to
>>>> the RTC.
>>>> 
>>>> Note that due to migration compatibility, port92 is optional in the south
>>>> bridges. It is always instantiated the isapc machine for simplicity.
>>>> 
>>>> Signed-off-by: Bernhard Beschow 
>>>> ---
>>>>   include/hw/i386/pc.h  |  2 +-
>>>>   include/hw/southbridge/ich9.h |  4 
>>>>   include/hw/southbridge/piix.h |  3 +++
>>>>   hw/i386/pc.c  | 18 --
>>>>   hw/i386/pc_piix.c |  9 +++--
>>>>   hw/i386/pc_q35.c  |  8 +---
>>>>   hw/isa/lpc_ich9.c |  9 +
>>>>   hw/isa/piix.c |  9 +
>>>>   hw/isa/Kconfig|  2 ++
>>>>   9 files changed, 52 insertions(+), 12 deletions(-)
>>> 
>>> I had a look at this (and did a bit of revision around 8042 and A20), and I 
>>> am starting to wonder if the PORT92 device isn't something that belongs to 
>>> the southbridge, but more specifically to the superio chip?
>> 
>> If there is agreement to model real hardware in QEMU, then I think that
>
>I think there's no such agreement and QEMU is more lax about it both for 
>historical reasons and to simplify machine models. Indeed, QEMU sometimes 
>models non-existing machines (e.g. the mac99 or virt boards) that don't 
>correspond to real hardware but allow guest OSes to boot. Even when modelllng 
>real hardware it's ofren modelled just enough for guests to work and unused 
>details are omitted for simplicity. It is recommended to follow what real 
>hardware does when modelling real hardware but not always required. Although 
>it might help both with verifying a device model and to compose machines with 
>these models to try to follow the real hardware.

Composing real machines and verifying device models is exactly what I'm after. 
I'm aware that QEMU provides virt machines such as the microvm, and from the 
context I didn't refer to these.

>
>> port 92 belongs into any device model where the hardware has one. All our 
>> PC-like southbridges (PIIX, ICH, VIA) have port 92. Many FDC37 including 
>> the FDC37M81x as used in the Malta board have one, too -- where it must 
>> first be enabled.
>
>So port92 is not a real hardware but a QEMU abstraction or model of some 
>functionality found in some machines. Real chips probably implement this in 
>different ways so we could either model this in these chips independently the 
>same way as real hardware does or use the abstracted model anywhere in our 
>machine model. Since this does not exist in real hardware as this abstract 
>model it also does not belong anywhere so we are free to put it where it's 
>most convenient or simple to do.

As mentioned already, port 92 is an integral part of PIIX, ICH, and VIA 
southbridges. That's why I want to move it there. My goal is to create 
different PC machines in a data-driven manner which model real boards. I want 
to see how low-level guests interact with the hardware, including e.g. how they 
set up the memory map.

>
>>> A couple of thoughts as to why I came to this conclusion: firstly the 
>>> superio chip is generally considered to be a single integrated 
>>> implementation of legacy IO devices, so this feels like a natural home for 
>>> the PORT92 device.
>> 
>>> Secondly the value of the "has-port92" property is controlled by 
>>> pcms->i8042_enabled, and this value is already passed into functions such 
>>> as pc_superio_init() for example.
>> 
>> Rhight. There, it also controls the presence of port 92. If we move port 92 
>> into the southbridges, we have to respect this command line switch there to 
>> preserve backward compatibility.
>> 
>> I wonder what `-M i8042` is supposed to do. If it is for modeling a 
>> stripped-down x86 system, why not use the microvm instead? How is it 
>> possible to omit an essential piece of hardware needed to boot x86 systems? 
>> Don't we need at least either one (i8042 or port 92)?
>
>Try git log -p 4ccd5fe22fe (found it via git blame and see what added that 
>property).

Alright, the intention was

Re: [PATCH 3/5] hw/isa: Embed TYPE_PORT92 in south bridges used in PC machines

2024-02-27 Thread Bernhard Beschow



Am 21. Februar 2024 11:53:21 UTC schrieb Mark Cave-Ayland 
:
>On 18/02/2024 13:16, Bernhard Beschow wrote:
>
>> Port 92 is an integral part of the PIIX and ICH south bridges, so 
>> instantiate it
>> there. The isapc machine now needs to instantiate it explicitly, analoguous 
>> to
>> the RTC.
>> 
>> Note that due to migration compatibility, port92 is optional in the south
>> bridges. It is always instantiated the isapc machine for simplicity.
>> 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   include/hw/i386/pc.h  |  2 +-
>>   include/hw/southbridge/ich9.h |  4 
>>   include/hw/southbridge/piix.h |  3 +++
>>   hw/i386/pc.c  | 18 --
>>   hw/i386/pc_piix.c |  9 +++--
>>   hw/i386/pc_q35.c  |  8 +---
>>   hw/isa/lpc_ich9.c |  9 +
>>   hw/isa/piix.c |  9 +
>>   hw/isa/Kconfig|  2 ++
>>   9 files changed, 52 insertions(+), 12 deletions(-)
>> 
>> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
>> index b2987209b1..a9ff1f5ab3 100644
>> --- a/include/hw/i386/pc.h
>> +++ b/include/hw/i386/pc.h
>> @@ -178,7 +178,7 @@ uint64_t pc_pci_hole64_start(void);
>>   DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus);
>>   void pc_basic_device_init(struct PCMachineState *pcms,
>> ISABus *isa_bus, qemu_irq *gsi,
>> -  ISADevice *rtc_state,
>> +  ISADevice *rtc_state, ISADevice *port92,
>> bool create_fdctrl,
>> uint32_t hpet_irqs);
>>   void pc_cmos_init(PCMachineState *pcms,
>> diff --git a/include/hw/southbridge/ich9.h b/include/hw/southbridge/ich9.h
>> index fd01649d04..d70a94f5e7 100644
>> --- a/include/hw/southbridge/ich9.h
>> +++ b/include/hw/southbridge/ich9.h
>> @@ -3,6 +3,7 @@
>> #include "hw/isa/apm.h"
>>   #include "hw/acpi/ich9.h"
>> +#include "hw/isa/port92.h"
>>   #include "hw/intc/ioapic.h"
>>   #include "hw/pci/pci.h"
>>   #include "hw/pci/pci_device.h"
>> @@ -32,6 +33,7 @@ struct ICH9LPCState {
>>   uint8_t irr[PCI_SLOT_MAX][PCI_NUM_PINS];
>> MC146818RtcState rtc;
>> +Port92State port92;
>>   APMState apm;
>>   ICH9LPCPMRegs pm;
>>   uint32_t sci_level; /* track sci level */
>> @@ -54,6 +56,8 @@ struct ICH9LPCState {
>>   uint8_t rst_cnt;
>>   MemoryRegion rst_cnt_mem;
>>   +bool has_port92;
>> +
>>   /* SMI feature negotiation via fw_cfg */
>>   uint64_t smi_host_features;   /* guest-invisible, host endian */
>>   uint8_t smi_host_features_le[8];  /* guest-visible, read-only, little
>> diff --git a/include/hw/southbridge/piix.h b/include/hw/southbridge/piix.h
>> index 86709ba2e4..35058529d1 100644
>> --- a/include/hw/southbridge/piix.h
>> +++ b/include/hw/southbridge/piix.h
>> @@ -15,6 +15,7 @@
>>   #include "hw/pci/pci_device.h"
>>   #include "hw/acpi/piix4.h"
>>   #include "hw/ide/pci.h"
>> +#include "hw/isa/port92.h"
>>   #include "hw/rtc/mc146818rtc.h"
>>   #include "hw/usb/hcd-uhci.h"
>>   @@ -56,6 +57,7 @@ struct PIIXState {
>>   int32_t pci_irq_levels_vmstate[PIIX_NUM_PIRQS];
>> MC146818RtcState rtc;
>> +Port92State port92;
>>   PCIIDEState ide;
>>   UHCIState uhci;
>>   PIIX4PMState pm;
>> @@ -71,6 +73,7 @@ struct PIIXState {
>>   bool has_acpi;
>>   bool has_pic;
>>   bool has_pit;
>> +bool has_port92;
>>   bool has_usb;
>>   bool smm_enabled;
>>   };
>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> index 0b11d4576e..8b601ea6cf 100644
>> --- a/hw/i386/pc.c
>> +++ b/hw/i386/pc.c
>> @@ -1160,7 +1160,7 @@ static void pc_superio_init(ISABus *isa_bus, bool 
>> create_fdctrl,
>>   int i;
>>   DriveInfo *fd[MAX_FD];
>>   qemu_irq *a20_line;
>> -ISADevice *fdc, *i8042, *port92, *vmmouse;
>> +ISADevice *fdc, *i8042, *vmmouse;
>> serial_hds_isa_init(isa_bus, 0, MAX_ISA_SERIAL_PORTS);
>>   parallel_hds_isa_init(isa_bus, MAX_PARALLEL_PORTS);
>> @@ -1193,18 +1193,15 @@ static void pc_superio_init(ISABus *isa_bus, bool 
>> create_fdctrl,
>>_abort);
>>   isa_realize_and_unref(vmmous

Re: [PATCH v2 10/15] hw/southbridge/ich9: Add the DMI-to-PCI bridge

2024-02-26 Thread Bernhard Beschow



Am 26. Februar 2024 11:14:09 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Instantiate TYPE_ICH_DMI_PCI_BRIDGE in TYPE_ICH9_SOUTHBRIDGE.
>
>Since the Q35 machine doesn't use it, add the 'd2p-enabled'
>property to disable it.
>
>Signed-off-by: Philippe Mathieu-Daudé 
>---
> include/hw/southbridge/ich9.h |  9 -
> hw/i386/pc_q35.c  |  1 +
> hw/southbridge/ich9.c | 27 +++
> hw/southbridge/Kconfig|  1 +
> 4 files changed, 29 insertions(+), 9 deletions(-)
>
>diff --git a/include/hw/southbridge/ich9.h b/include/hw/southbridge/ich9.h
>index 162ae3baa1..b9122d299d 100644
>--- a/include/hw/southbridge/ich9.h
>+++ b/include/hw/southbridge/ich9.h
>@@ -108,15 +108,6 @@ struct ICH9LPCState {
> #define ICH9_USB_UHCI1_DEV  29
> #define ICH9_USB_UHCI1_FUNC 0
> 
>-/* D30:F0 DMI-to-PCI bridge */
>-#define ICH9_D2P_BRIDGE "ICH9 D2P BRIDGE"
>-#define ICH9_D2P_BRIDGE_SAVEVM_VERSION  0
>-
>-#define ICH9_D2P_BRIDGE_DEV 30
>-#define ICH9_D2P_BRIDGE_FUNC0
>-
>-#define ICH9_D2P_SECONDARY_DEFAULT  (256 - 8)
>-
> /* D31:F0 LPC Processor Interface */
> #define ICH9_RST_CNT_IOPORT 0xCF9
> 
>diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>index 8c8a2f65b8..f951cf1e3a 100644
>--- a/hw/i386/pc_q35.c
>+++ b/hw/i386/pc_q35.c
>@@ -226,6 +226,7 @@ static void pc_q35_init(MachineState *machine)
> object_property_add_child(OBJECT(machine), "ich9", OBJECT(ich9));
> object_property_set_link(OBJECT(ich9), "mch-pcie-bus",
>  OBJECT(pcms->pcibus), _abort);
>+qdev_prop_set_bit(ich9, "d2p-enabled", false);
> qdev_realize_and_unref(ich9, NULL, _fatal);
> 
> /* create ISA bus */
>diff --git a/hw/southbridge/ich9.c b/hw/southbridge/ich9.c
>index f3a9b932ab..8c4356ff74 100644
>--- a/hw/southbridge/ich9.c
>+++ b/hw/southbridge/ich9.c
>@@ -12,16 +12,23 @@
> #include "hw/qdev-properties.h"
> #include "hw/southbridge/ich9.h"
> #include "hw/pci/pci.h"
>+#include "hw/pci-bridge/ich9_dmi.h"
>+
>+#define ICH9_D2P_DEVFN  PCI_DEVFN(30, 0)

Something along the lines of ICH9_DMI_PCI_DEVFN seems more clear to me.

> 
> struct ICH9State {
> DeviceState parent_obj;
> 
>+I82801b11Bridge d2p;

Same here and essentially all identifiers and properties with "d2p" in their 
name.

Best regards,
Bernhard

>+
> PCIBus *pci_bus;
>+bool d2p_enabled;
> };
> 
> static Property ich9_props[] = {
> DEFINE_PROP_LINK("mch-pcie-bus", ICH9State, pci_bus,
>  TYPE_PCIE_BUS, PCIBus *),
>+DEFINE_PROP_BOOL("d2p-enabled", ICH9State, d2p_enabled, true),
> DEFINE_PROP_END_OF_LIST(),
> };
> 
>@@ -29,6 +36,22 @@ static void ich9_init(Object *obj)
> {
> }
> 
>+static bool ich9_realize_d2p(ICH9State *s, Error **errp)
>+{
>+if (!module_object_class_by_name(TYPE_ICH_DMI_PCI_BRIDGE)) {
>+error_setg(errp, "DMI-to-PCI function not available in this build");
>+return false;
>+}
>+object_initialize_child(OBJECT(s), "d2p", >d2p, 
>TYPE_ICH_DMI_PCI_BRIDGE);
>+qdev_prop_set_int32(DEVICE(>d2p), "addr", ICH9_D2P_DEVFN);
>+if (!qdev_realize(DEVICE(>d2p), BUS(s->pci_bus), errp)) {
>+return false;
>+}
>+object_property_add_alias(OBJECT(s), "pci.0", OBJECT(>d2p), "pci.0");
>+
>+return true;
>+}
>+
> static void ich9_realize(DeviceState *dev, Error **errp)
> {
> ICH9State *s = ICH9_SOUTHBRIDGE(dev);
>@@ -37,6 +60,10 @@ static void ich9_realize(DeviceState *dev, Error **errp)
> error_setg(errp, "'pcie-bus' property must be set");
> return;
> }
>+
>+if (s->d2p_enabled && !ich9_realize_d2p(s, errp)) {
>+return;
>+}
> }
> 
> static void ich9_class_init(ObjectClass *klass, void *data)
>diff --git a/hw/southbridge/Kconfig b/hw/southbridge/Kconfig
>index 852b7f346f..db7259bf6f 100644
>--- a/hw/southbridge/Kconfig
>+++ b/hw/southbridge/Kconfig
>@@ -3,3 +3,4 @@
> config ICH9
> bool
> depends on PCI_EXPRESS
>+imply I82801B11



Re: [PATCH v2 00/15] hw/southbridge: Extract ICH9 QOM container model

2024-02-26 Thread Bernhard Beschow



Am 26. Februar 2024 11:13:59 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Since v1 [1]:
>- Rebased on top of Bernhard patches
>- Rename files with 'ich9_' prefix (Bernhard)
>
>Hi,
>
>I have a long standing southbridge QOM rework branches. Since
>Bernhard is actively working on the PIIX, I'll try to refresh
>and post. This is also motivated by the Dynamic Machine work
>where we are trying to figure the ideal DSL for QEMU, so having
>complex models well designed help.
>
>Here we introduce the ICH9 'southbridge' as a QOM container.
>Since the chipset comes as a whole, we shouldn't instantiate
>its components separately. However in order to maintain old
>code we expose some properties to configure the container and
>not introduce any change for the Q35 machine. There is no
>migration change, only QOM objects moved around.

I really like the simplicity of the machine code and that the ICH9 southbridge 
becomes a proper device rather than being scattered around in machine code. 
I've made some reviews in form of a branch: 
https://github.com/shentok/qemu/commits/philmd/ich9_qom-v2/

>
>More work remain in the LPC function (more code to remove from
>Q35). Maybe worth doing in parallel with the PIIX to clean both
>PC machines.

Would be nice if the pattern could then also be applied to the VIA 
southbridges, otherwise this could break my via-apollo-pro-133t branch: 
https://github.com/shentok/qemu/tree/via-apollo-pro-133t

Best regards,
Bernhard

>
>Also we'd need to decouple the cpu_interrupt() calls between hw/
>and target/.
>
>Note that GSI is currently broken [2]. Once the LPC/ISA part is
>done, it might be easier to fix it.
>
>[1] 
>https://lore.kernel.org/qemu-devel/20240219163855.87326-1-phi...@linaro.org/
>[2] 
>https://lore.kernel.org/qemu-devel/cd0e13c6-c03d-411f-83a5-1d4d28ea4...@linaro.org/
>
>Philippe Mathieu-Daudé (15):
>  MAINTAINERS: Add 'ICH9 South Bridge' section
>  hw/i386/q35: Add local 'lpc_obj' variable
>  hw/acpi/ich9: Restrict definitions from 'hw/southbridge/ich9.h'
>  hw/acpi/ich9_tco: Include 'ich9' in names
>  hw/acpi/ich9_tco: Restrict ich9_generate_smi() declaration
>  hw/ide: Rename ich.c -> ich9_ahci.c
>  hw/i2c/smbus: Extract QOM ICH9 definitions to 'ich9_smbus.h'
>  hw/pci-bridge: Extract QOM ICH definitions to 'ich9_dmi.h'
>  hw/southbridge/ich9: Introduce TYPE_ICH9_SOUTHBRIDGE stub
>  hw/southbridge/ich9: Add the DMI-to-PCI bridge
>  hw/southbridge/ich9: Add a AHCI function
>  hw/southbridge/ich9: Add the SMBus function
>  hw/southbridge/ich9: Add the USB EHCI/UHCI functions
>  hw/southbridge/ich9: Extract LPC definitions to 'hw/isa/ich9_lpc.h'
>  hw/southbridge/ich9: Add the LPC / ISA bridge function
>
> MAINTAINERS   |  21 +-
> include/hw/acpi/ich9.h|  15 ++
> include/hw/acpi/ich9_tco.h|   6 +-
> include/hw/i2c/ich9_smbus.h   |  25 +++
> include/hw/isa/ich9_lpc.h | 166 +++
> include/hw/pci-bridge/ich9_dmi.h  |  20 ++
> include/hw/southbridge/ich9.h | 235 +-
> hw/acpi/ich9.c|   9 +-
> hw/acpi/ich9_tco.c|   5 +-
> hw/i2c/{smbus_ich9.c => ich9_smbus.c} |  36 +++-
> hw/i386/acpi-build.c  |   1 +
> hw/i386/pc_q35.c  | 126 +++-
> hw/ide/{ich.c => ich9_ahci.c} |   0
> hw/isa/{lpc_ich9.c => ich9_lpc.c} |  37 +++-
> hw/pci-bridge/{i82801b11.c => ich9_dmi.c} |  11 +-
> hw/southbridge/ich9.c | 213 
> tests/qtest/tco-test.c|   2 +-
> hw/Kconfig|   1 +
> hw/i2c/meson.build|   2 +-
> hw/i386/Kconfig   |   3 +-
> hw/ide/meson.build|   2 +-
> hw/isa/meson.build|   2 +-
> hw/meson.build|   1 +
> hw/pci-bridge/meson.build |   2 +-
> hw/southbridge/Kconfig|  11 +
> hw/southbridge/meson.build|   3 +
> 26 files changed, 587 insertions(+), 368 deletions(-)
> create mode 100644 include/hw/i2c/ich9_smbus.h
> create mode 100644 include/hw/isa/ich9_lpc.h
> create mode 100644 include/hw/pci-bridge/ich9_dmi.h
> rename hw/i2c/{smbus_ich9.c => ich9_smbus.c} (77%)
> rename hw/ide/{ich.c => ich9_ahci.c} (100%)
> rename hw/isa/{lpc_ich9.c => ich9_lpc.c} (95%)
> rename hw/pci-bridge/{i82801b11.c => ich9_dmi.c} (95%)
> create mode 100644 hw/southbridge/ich9.c
> create mode 100644 hw/southbridge/Kconfig
> create mode 100644 hw/southbridge/meson.build
>



[PATCH 0/2] Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"

2024-02-26 Thread Bernhard Beschow
As reported by Volker [1], commit 6f6ad2b24582 "hw/i386/pc: Confine system
flash handling to pc_sysfw" causes a regression when specifying the property
`-M pflash0` in the PCI PC machines:
  qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found
Revert the commit for now until a solution is found.

Best regards,
Bernhard

[1] 
https://lore.kernel.org/qemu-devel/9e82a04b-f2c1-4e34-b4b6-46a0581b5...@t-online.de/

Bernhard Beschow (2):
  Revert "hw/i386/pc_sysfw: Inline pc_system_flash_create() and remove
it"
  Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"

 include/hw/i386/pc.h |  2 ++
 hw/i386/pc.c |  1 +
 hw/i386/pc_piix.c|  1 +
 hw/i386/pc_sysfw.c   | 17 +
 4 files changed, 17 insertions(+), 4 deletions(-)

-- 
2.44.0




[PATCH 2/2] Revert "hw/i386/pc: Confine system flash handling to pc_sysfw"

2024-02-26 Thread Bernhard Beschow
Specifying the property `-M pflash0` results in a regression:
  qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found
Revert the change for now until a solution is found.

This reverts commit 6f6ad2b24582593d8feb00434ce2396840666227.

Reported-by: Volker Rümelin 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h | 2 ++
 hw/i386/pc.c | 1 +
 hw/i386/pc_piix.c| 1 +
 hw/i386/pc_sysfw.c   | 6 ++
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index e88468131a..0f9c1a45fc 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -191,6 +191,8 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
 #define TYPE_PORT92 "port92"
 
 /* pc_sysfw.c */
+void pc_system_flash_create(PCMachineState *pcms);
+void pc_system_flash_cleanup_unused(PCMachineState *pcms);
 void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion *rom_memory);
 bool pc_system_ovmf_table_find(const char *entry, uint8_t **data,
int *data_len);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f8eb684a49..2ad8de5097 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1733,6 +1733,7 @@ static void pc_machine_initfn(Object *obj)
 #endif
 pcms->default_bus_bypass_iommu = false;
 
+pc_system_flash_create(pcms);
 pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
 object_property_add_alias(OBJECT(pcms), "pcspk-audiodev",
   OBJECT(pcms->pcspk), "audiodev");
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ec7c07b362..34203927e1 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -231,6 +231,7 @@ static void pc_init1(MachineState *machine,
 assert(machine->ram_size == x86ms->below_4g_mem_size +
 x86ms->above_4g_mem_size);
 
+pc_system_flash_cleanup_unused(pcms);
 if (machine->kernel_filename != NULL) {
 /* For xen HVM direct kernel boot, load linux here */
 xen_load_linux(pcms);
diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b9c1eb352d..3efabbbab2 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -91,7 +91,7 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
 return PFLASH_CFI01(dev);
 }
 
-static void pc_system_flash_create(PCMachineState *pcms)
+void pc_system_flash_create(PCMachineState *pcms)
 {
 PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 
@@ -103,7 +103,7 @@ static void pc_system_flash_create(PCMachineState *pcms)
 }
 }
 
-static void pc_system_flash_cleanup_unused(PCMachineState *pcms)
+void pc_system_flash_cleanup_unused(PCMachineState *pcms)
 {
 char *prop_name;
 int i;
@@ -210,8 +210,6 @@ void pc_system_firmware_init(PCMachineState *pcms,
 return;
 }
 
-pc_system_flash_create(pcms);
-
 /* Map legacy -drive if=pflash to machine properties */
 for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
 pflash_cfi01_legacy_drive(pcms->flash[i],
-- 
2.44.0




[PATCH 1/2] Revert "hw/i386/pc_sysfw: Inline pc_system_flash_create() and remove it"

2024-02-26 Thread Bernhard Beschow
Commit 6f6ad2b24582 "hw/i386/pc: Confine system flash handling to pc_sysfw"
causes a regression when specifying the property `-M pflash0` in the PCI PC
machines:
  qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found
In order to revert the commit, the commit below must be reverted first.

This reverts commit cb05cc16029bb0a61ac5279ab7b3b90dcf2aa69f.

Signed-off-by: Bernhard Beschow 
---
 hw/i386/pc_sysfw.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
index b02e285579..b9c1eb352d 100644
--- a/hw/i386/pc_sysfw.c
+++ b/hw/i386/pc_sysfw.c
@@ -91,6 +91,18 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
 return PFLASH_CFI01(dev);
 }
 
+static void pc_system_flash_create(PCMachineState *pcms)
+{
+PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
+
+if (pcmc->pci_enabled) {
+pcms->flash[0] = pc_pflash_create(pcms, "system.flash0",
+  "pflash0");
+pcms->flash[1] = pc_pflash_create(pcms, "system.flash1",
+  "pflash1");
+}
+}
+
 static void pc_system_flash_cleanup_unused(PCMachineState *pcms)
 {
 char *prop_name;
@@ -198,8 +210,7 @@ void pc_system_firmware_init(PCMachineState *pcms,
 return;
 }
 
-pcms->flash[0] = pc_pflash_create(pcms, "system.flash0", "pflash0");
-pcms->flash[1] = pc_pflash_create(pcms, "system.flash1", "pflash1");
+pc_system_flash_create(pcms);
 
 /* Map legacy -drive if=pflash to machine properties */
 for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
-- 
2.44.0




Re: [PULL 14/25] hw/i386/pc: Confine system flash handling to pc_sysfw

2024-02-25 Thread Bernhard Beschow



Am 25. Februar 2024 13:03:46 UTC schrieb "Volker Rümelin" :
>Am 21.02.24 um 22:16 schrieb Philippe Mathieu-Daudé:
>> From: Bernhard Beschow 
>>
>> Rather than distributing PC system flash handling across three files, let's
>> confine it to one. Now, pc_system_firmware_init() creates, configures and 
>> cleans
>> up the system flash which makes the code easier to understand. It also avoids
>> the extra call to pc_system_flash_cleanup_unused() in the Xen case.
>>
>> Signed-off-by: Bernhard Beschow 
>> Reviewed-by: Philippe Mathieu-Daudé 
>> Message-ID: <20240208220349.4948-7-shen...@gmail.com>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  include/hw/i386/pc.h | 2 --
>>  hw/i386/pc.c | 1 -
>>  hw/i386/pc_piix.c| 1 -
>>  hw/i386/pc_sysfw.c   | 6 --
>>  4 files changed, 4 insertions(+), 6 deletions(-)
>
>Hi Bernhard,

Hi Volker,

>
>this patch breaks QEMU on my system.
>
>./qemu-system-x86_64 -machine q35,pflash0=pflash0-storage -blockdev
>driver=file,node-name=pflash0-storage,filename=/usr/share/qemu/ovmf-x86_64.bin,read-only=true
>qemu-system-x86_64: Property 'pc-q35-9.0-machine.pflash0' not found
>
>I had to revert cb05cc1602 ("hw/i386/pc_sysfw: Inline
>pc_system_flash_create() and remove it") and 6f6ad2b245 ("hw/i386/pc:
>Confine system flash handling to pc_sysfw") to make it work again.

In my tests I've followed 
https://wiki.archlinux.org/title/QEMU#Booting_in_UEFI_mode for both pc and q35 
machine, and therefore missed the machine properties. If there is no way to fix 
it with compat properties or the like, I propose to revert the two patches 
until a different solution is found.

Best regards,
Bernhard

>
>With best regards,
>Volker
>
>> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
>> index 0a8a96600c..e8f4af5d5c 100644
>> --- a/include/hw/i386/pc.h
>> +++ b/include/hw/i386/pc.h
>> @@ -193,8 +193,6 @@ void pc_i8259_create(ISABus *isa_bus, qemu_irq 
>> *i8259_irqs);
>>  #define TYPE_PORT92 "port92"
>>  
>>  /* pc_sysfw.c */
>> -void pc_system_flash_create(PCMachineState *pcms);
>> -void pc_system_flash_cleanup_unused(PCMachineState *pcms);
>>  void pc_system_firmware_init(PCMachineState *pcms, MemoryRegion 
>> *rom_memory);
>>  bool pc_system_ovmf_table_find(const char *entry, uint8_t **data,
>> int *data_len);
>> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> index e526498164..1ee41a5e56 100644
>> --- a/hw/i386/pc.c
>> +++ b/hw/i386/pc.c
>> @@ -1733,7 +1733,6 @@ static void pc_machine_initfn(Object *obj)
>>  #endif
>>  pcms->default_bus_bypass_iommu = false;
>>  
>> -pc_system_flash_create(pcms);
>>  pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
>>  object_property_add_alias(OBJECT(pcms), "pcspk-audiodev",
>>OBJECT(pcms->pcspk), "audiodev");
>> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
>> index 34203927e1..ec7c07b362 100644
>> --- a/hw/i386/pc_piix.c
>> +++ b/hw/i386/pc_piix.c
>> @@ -231,7 +231,6 @@ static void pc_init1(MachineState *machine,
>>  assert(machine->ram_size == x86ms->below_4g_mem_size +
>>  x86ms->above_4g_mem_size);
>>  
>> -pc_system_flash_cleanup_unused(pcms);
>>  if (machine->kernel_filename != NULL) {
>>  /* For xen HVM direct kernel boot, load linux here */
>>  xen_load_linux(pcms);
>> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
>> index c8d9e71b88..b4c3833352 100644
>> --- a/hw/i386/pc_sysfw.c
>> +++ b/hw/i386/pc_sysfw.c
>> @@ -91,7 +91,7 @@ static PFlashCFI01 *pc_pflash_create(PCMachineState *pcms,
>>  return PFLASH_CFI01(dev);
>>  }
>>  
>> -void pc_system_flash_create(PCMachineState *pcms)
>> +static void pc_system_flash_create(PCMachineState *pcms)
>>  {
>>  PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
>>  
>> @@ -103,7 +103,7 @@ void pc_system_flash_create(PCMachineState *pcms)
>>  }
>>  }
>>  
>> -void pc_system_flash_cleanup_unused(PCMachineState *pcms)
>> +static void pc_system_flash_cleanup_unused(PCMachineState *pcms)
>>  {
>>  char *prop_name;
>>  int i;
>> @@ -212,6 +212,8 @@ void pc_system_firmware_init(PCMachineState *pcms,
>>  return;
>>  }
>>  
>> +pc_system_flash_create(pcms);
>> +
>>  /* Map legacy -drive if=pflash to machine properties */
>>  for (i = 0; i < ARRAY_SIZE(pcms->flash); i++) {
>>  pflash_cfi01_legacy_drive(pcms->flash[i],
>



Re: [PATCH 9/9] hw/i386/pc_{piix, q35}: Eliminate local pci_bus/pci_host variables

2024-02-25 Thread Bernhard Beschow



Am 21. Februar 2024 15:50:33 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 8/2/24 23:03, Bernhard Beschow wrote:
>> There is no advantage in having these local variables which 1/ needlessly 
>> have
>> different identifiers in both machines and 2/ which are redundant to 
>> pcms->bus
>> which is almost as short.
>> 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   hw/i386/pc_piix.c | 14 ++
>>   hw/i386/pc_q35.c  | 16 +++-
>>   2 files changed, 13 insertions(+), 17 deletions(-)
>
>IMO it is a design mistake to have these fields in PCMachineState:
>
> 27 typedef struct PCMachineState {
>
> 36 /* Pointers to devices and objects: */
> 37 PCIBus *bus;
> 38 I2CBus *smbus;
> 39 PFlashCFI01 *flash[2];
> 40 ISADevice *pcspk;
> 41 DeviceState *iommu;
> 42 BusState *idebus[MAX_IDE_BUS];

Any ideas on how to resolve these? `flash` might be easy now. What about the 
buses in particular?

Best regards,
Bernhard

>
>Anyhow, back to your patch, please rename 'bus' -> 'pcibus'. Maybe
>in a preliminary patch?



Re: [PATCH v2 0/6] Simplify initialization of PC machines

2024-02-24 Thread Bernhard Beschow



Am 24. Februar 2024 13:58:45 UTC schrieb Bernhard Beschow :
>The series aims to simplify the initialization process of all PC-based machines
>
>by streamlining redundant code.
>
>
>
>Since I haven't seen patches on the list so far for folding CMOS data
>
>generation into pc.c, which frees all PC machines from performing this duty
>
>explicitly, I've appended this cleanup as the last two patches.
>
>
>
>Testing done:
>
>* `make check`
>

The `boot-order-test` actually fails. We'd have to ignore the last patch for 
now.

Best regards,
Bernhard

>* `make check-avocado`
>
>* I'm sending this series from within a VM containing these changes.
>
>
>
>v2:
>
>* Rebase onto master, leaving only patches 1, 3, and 5
>
>* Patch 2: Rename "bus" attribute to "pcibus" (Phil)
>
>* Patch 4: Spotted while rebasing
>
>* Patch 6: New patch possible after [1]
>
>
>
>Best regards,
>
>Bernhard
>
>
>
>[1]
>
>https://patchew.org/QEMU/20240221211626.48190-1-phi...@linaro.org/20240221211626
>
>.48190-10-phi...@linaro.org/
>
>
>
>Bernhard Beschow (6):
>
>  hw/i386/x86: Let ioapic_init_gsi() take parent as pointer
>
>  hw/i386/pc: Rename "bus" attribute to "pcibus"
>
>  hw/i386/pc_{piix,q35}: Eliminate local pci_bus/pci_host variables
>
>  hw/i386/pc: Remove unneeded class attribute "kvmclock_enabled"
>
>  hw/i386/pc: Populate RTC attribute directly
>
>  hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove
>
>it
>
>
>
> include/hw/i386/pc.h |  5 +
>
> include/hw/i386/x86.h|  2 +-
>
> hw/i386/acpi-build.c |  2 +-
>
> hw/i386/amd_iommu.c  |  2 +-
>
> hw/i386/intel_iommu.c|  2 +-
>
> hw/i386/kvm/xen_evtchn.c |  2 +-
>
> hw/i386/microvm.c|  2 +-
>
> hw/i386/pc.c | 27 --
>
> hw/i386/pc_piix.c| 42 +---
>
> hw/i386/pc_q35.c | 25 ++--
>
> hw/i386/x86-iommu.c  |  2 +-
>
> hw/i386/x86.c|  7 +++
>
> 12 files changed, 43 insertions(+), 77 deletions(-)
>
>
>
>-- >
>2.44.0
>
>
>



Re: [PATCH 0/9] Simplify initialization of PC machines

2024-02-24 Thread Bernhard Beschow



Am 22. Februar 2024 15:25:01 UTC schrieb "Michael S. Tsirkin" :
>On Thu, Feb 08, 2024 at 11:03:40PM +0100, Bernhard Beschow wrote:
>> The series aims to simplify the initialization process of all PC-based 
>> machines.
>> 
>> It consists of streamlining redundant code, as well as consolidating the 
>> setup
>> of system flash and generation of smbios data which are currently fairly
>> distributed.
>> 
>> These changes are expected to make the code easier to understand and 
>> maintain.
>> 
>> Best regards,
>> Bernhard
>
>
>This looks good to me overall.
>
>Reviewed-by: Michael S. Tsirkin 
>
>I see Philippe started queueing these, fine by me.

Thanks so far to all involved! I've just sent v2: 
https://lore.kernel.org/qemu-devel/20240224135851.100361-1-shen...@gmail.com/

Best regars,
Bernhard

>
>> Bernhard Beschow (9):
>>   hw/i386/x86: Let ioapic_init_gsi() take parent as pointer
>>   hw/i386/pc_piix: Share pc_cmos_init() invocation between pc and isapc
>> machines
>>   hw/i386/x86: Turn apic_xrupt_override into class attribute
>>   hw/i386/pc: Merge pc_guest_info_init() into pc_machine_initfn()
>>   hw/i386/pc: Defer smbios_set_defaults() to machine_done
>>   hw/i386/pc: Confine system flash handling to pc_sysfw
>>   hw/i386/pc_sysfw: Inline pc_system_flash_create() and remove it
>>   hw/i386/pc: Populate RTC attribute directly
>>   hw/i386/pc_{piix,q35}: Eliminate local pci_bus/pci_host variables
>> 
>>  hw/i386/fw_cfg.h  |  3 ++-
>>  include/hw/i386/pc.h  |  5 
>>  include/hw/i386/x86.h |  5 ++--
>>  hw/i386/acpi-common.c |  3 ++-
>>  hw/i386/fw_cfg.c  | 12 +-
>>  hw/i386/microvm.c |  2 +-
>>  hw/i386/pc.c  | 25 +---
>>  hw/i386/pc_piix.c | 55 ++-
>>  hw/i386/pc_q35.c  | 38 ++
>>  hw/i386/pc_sysfw.c| 17 -
>>  hw/i386/x86.c |  7 +++---
>>  11 files changed, 62 insertions(+), 110 deletions(-)
>> 
>> -- 
>> 2.43.0
>> 
>



[PATCH v2 3/6] hw/i386/pc_{piix, q35}: Eliminate local pci_bus/pci_host variables

2024-02-24 Thread Bernhard Beschow
There is no advantage in having these local variables which 1/ needlessly have
different identifiers in both machines and 2/ which are redundant to pcms->bus
which is almost as short.

Signed-off-by: Bernhard Beschow 
Reviewed-by: Michael S. Tsirkin 
---
 hw/i386/pc_piix.c | 14 ++
 hw/i386/pc_q35.c  | 16 +++-
 2 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 3393b93007..814d24326d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -108,7 +108,6 @@ static void pc_init1(MachineState *machine,
 MemoryRegion *system_memory = get_system_memory();
 MemoryRegion *system_io = get_system_io();
 Object *phb = NULL;
-PCIBus *pci_bus = NULL;
 ISABus *isa_bus;
 Object *piix4_pm = NULL;
 qemu_irq smi_irq;
@@ -212,11 +211,10 @@ static void pc_init1(MachineState *machine,
 _fatal);
 sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), _fatal);
 
-pci_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pci.0"));
-pci_bus_map_irqs(pci_bus,
+pcms->pcibus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pci.0"));
+pci_bus_map_irqs(pcms->pcibus,
  xen_enabled() ? xen_pci_slot_get_pirq
: pc_pci_slot_get_pirq);
-pcms->pcibus = pci_bus;
 
 hole64_size = object_property_get_uint(phb,
PCI_HOST_PROP_PCI_HOLE64_SIZE,
@@ -261,7 +259,7 @@ static void pc_init1(MachineState *machine,
 for (i = 0; i < ISA_NUM_IRQS; i++) {
 qdev_connect_gpio_out_named(dev, "isa-irqs", i, x86ms->gsi[i]);
 }
-pci_realize_and_unref(pci_dev, pci_bus, _fatal);
+pci_realize_and_unref(pci_dev, pcms->pcibus, _fatal);
 
 if (xen_enabled()) {
 pci_device_set_intx_routing_notifier(
@@ -273,7 +271,7 @@ static void pc_init1(MachineState *machine,
  * connected to the IOAPIC directly.
  * These additional routes can be discovered through ACPI.
  */
-pci_bus_irqs(pci_bus, xen_intx_set_irq, pci_dev,
+pci_bus_irqs(pcms->pcibus, xen_intx_set_irq, pci_dev,
  XEN_IOAPIC_NUM_PIRQS);
 }
 
@@ -310,7 +308,7 @@ static void pc_init1(MachineState *machine,
 x86_register_ferr_irq(x86ms->gsi[13]);
 }
 
-pc_vga_init(isa_bus, pcmc->pci_enabled ? pci_bus : NULL);
+pc_vga_init(isa_bus, pcmc->pci_enabled ? pcms->pcibus : NULL);
 
 assert(pcms->vmport != ON_OFF_AUTO__MAX);
 if (pcms->vmport == ON_OFF_AUTO_AUTO) {
@@ -321,7 +319,7 @@ static void pc_init1(MachineState *machine,
 pc_basic_device_init(pcms, isa_bus, x86ms->gsi, rtc_state, true,
  0x4);
 
-pc_nic_init(pcmc, isa_bus, pci_bus);
+pc_nic_init(pcmc, isa_bus, pcms->pcibus);
 
 #ifdef CONFIG_IDE_ISA
 if (!pcmc->pci_enabled) {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 734d9bedb2..2fa4efb52f 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -122,7 +122,6 @@ static void pc_q35_init(MachineState *machine)
 PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(machine);
 Object *phb;
-PCIBus *host_bus;
 PCIDevice *lpc;
 DeviceState *lpc_dev;
 ISADevice *rtc_state;
@@ -216,8 +215,7 @@ static void pc_q35_init(MachineState *machine)
 sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), _fatal);
 
 /* pci */
-host_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pcie.0"));
-pcms->pcibus = host_bus;
+pcms->pcibus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pcie.0"));
 
 /* irq lines */
 gsi_state = pc_gsi_create(>gsi, true);
@@ -231,7 +229,7 @@ static void pc_q35_init(MachineState *machine)
 for (i = 0; i < IOAPIC_NUM_PINS; i++) {
 qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i, x86ms->gsi[i]);
 }
-pci_realize_and_unref(lpc, host_bus, _fatal);
+pci_realize_and_unref(lpc, pcms->pcibus, _fatal);
 
 rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(lpc), "rtc"));
 
@@ -283,7 +281,7 @@ static void pc_q35_init(MachineState *machine)
 AHCIPCIState *ich9;
 
 /* ahci and SATA device, for q35 1 ahci controller is built-in */
-pdev = pci_create_simple_multifunction(host_bus,
+pdev = pci_create_simple_multifunction(pcms->pcibus,
PCI_DEVFN(ICH9_SATA1_DEV,
  ICH9_SATA1_FUNC),
"ich9-ahci");
@@ -297,14 +295,14 @@ static void pc_q35_init(MachineState *machine)
 
 if (machine_usb(machine)) {
 /* Should we create 6 UHCI according to ich9 spec? */
-ehci_cre

[PATCH v2 5/6] hw/i386/pc: Populate RTC attribute directly

2024-02-24 Thread Bernhard Beschow
Both the piix and the q35 machines introduce an rtc_state variable and defer the
initialization of the X86MachineState::rtc attribute to pc_cmos_init(). Resolve
this complication which makes pc_cmos_init() do what it says on the tin.

Signed-off-by: Bernhard Beschow 
Reviewed-by: Michael S. Tsirkin 
---
 hw/i386/pc.c  |  8 
 hw/i386/pc_piix.c | 15 +++
 hw/i386/pc_q35.c  |  7 +++
 3 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a80f809b83..880e95de26 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -611,14 +611,6 @@ void pc_cmos_init(PCMachineState *pcms,
 mc146818rtc_set_cmos_data(s, 0x5c, val >> 8);
 mc146818rtc_set_cmos_data(s, 0x5d, val >> 16);
 
-object_property_add_link(OBJECT(pcms), "rtc_state",
- TYPE_ISA_DEVICE,
- (Object **)>rtc,
- object_property_allow_set_link,
- OBJ_PROP_LINK_STRONG);
-object_property_set_link(OBJECT(pcms), "rtc_state", OBJECT(s),
- _abort);
-
 set_boot_dev(s, MACHINE(pcms)->boot_config.order, _fatal);
 
 val = 0;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 49d5d48db9..ce6aad758d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -112,7 +112,6 @@ static void pc_init1(MachineState *machine,
 Object *piix4_pm = NULL;
 qemu_irq smi_irq;
 GSIState *gsi_state;
-ISADevice *rtc_state;
 MemoryRegion *ram_memory;
 MemoryRegion *pci_memory = NULL;
 MemoryRegion *rom_memory = system_memory;
@@ -276,8 +275,8 @@ static void pc_init1(MachineState *machine,
 }
 
 isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(pci_dev), "isa.0"));
-rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(pci_dev),
- "rtc"));
+x86ms->rtc = ISA_DEVICE(object_resolve_path_component(OBJECT(pci_dev),
+  "rtc"));
 piix4_pm = object_resolve_path_component(OBJECT(pci_dev), "pm");
 dev = DEVICE(object_resolve_path_component(OBJECT(pci_dev), "ide"));
 pci_ide_create_devs(PCI_DEVICE(dev));
@@ -288,9 +287,9 @@ static void pc_init1(MachineState *machine,
   _abort);
 isa_bus_register_input_irqs(isa_bus, x86ms->gsi);
 
-rtc_state = isa_new(TYPE_MC146818_RTC);
-qdev_prop_set_int32(DEVICE(rtc_state), "base_year", 2000);
-isa_realize_and_unref(rtc_state, isa_bus, _fatal);
+x86ms->rtc = isa_new(TYPE_MC146818_RTC);
+qdev_prop_set_int32(DEVICE(x86ms->rtc), "base_year", 2000);
+isa_realize_and_unref(x86ms->rtc, isa_bus, _fatal);
 
 i8257_dma_init(OBJECT(machine), isa_bus, 0);
 pcms->hpet_enabled = false;
@@ -316,7 +315,7 @@ static void pc_init1(MachineState *machine,
 }
 
 /* init basic PC hardware */
-pc_basic_device_init(pcms, isa_bus, x86ms->gsi, rtc_state, true,
+pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc, true,
  0x4);
 
 pc_nic_init(pcmc, isa_bus, pcms->pcibus);
@@ -343,7 +342,7 @@ static void pc_init1(MachineState *machine,
 }
 #endif
 
-pc_cmos_init(pcms, rtc_state);
+pc_cmos_init(pcms, x86ms->rtc);
 
 if (piix4_pm) {
 smi_irq = qemu_allocate_irq(pc_acpi_smi_interrupt, first_cpu, 0);
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 2fa4efb52f..e0b3f55a02 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -124,7 +124,6 @@ static void pc_q35_init(MachineState *machine)
 Object *phb;
 PCIDevice *lpc;
 DeviceState *lpc_dev;
-ISADevice *rtc_state;
 MemoryRegion *system_memory = get_system_memory();
 MemoryRegion *system_io = get_system_io();
 MemoryRegion *pci_memory = g_new(MemoryRegion, 1);
@@ -231,7 +230,7 @@ static void pc_q35_init(MachineState *machine)
 }
 pci_realize_and_unref(lpc, pcms->pcibus, _fatal);
 
-rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(lpc), "rtc"));
+x86ms->rtc = ISA_DEVICE(object_resolve_path_component(OBJECT(lpc), "rtc"));
 
 object_property_add_link(OBJECT(machine), PC_MACHINE_ACPI_DEVICE_PROP,
  TYPE_HOTPLUG_HANDLER,
@@ -273,7 +272,7 @@ static void pc_q35_init(MachineState *machine)
 }
 
 /* init basic PC hardware */
-pc_basic_device_init(pcms, isa_bus, x86ms->gsi, rtc_state, !mc->no_floppy,
+pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc, !mc->no_floppy,
  0xff0104);
 
 if (pcms->sata_enabled) {
@@ -311,7 +310,7 @@ static void pc_q35_init(MachineState *machine)
 smbus_eeprom_init(pcms->smbus, 8, NULL, 0);
 }

[PATCH v2 1/6] hw/i386/x86: Let ioapic_init_gsi() take parent as pointer

2024-02-24 Thread Bernhard Beschow
Rather than taking a QOM name which has to be resolved, let's pass the parent
directly as pointer. This simplifies the code.

Signed-off-by: Bernhard Beschow 
Reviewed-by: Michael S. Tsirkin 
---
 include/hw/i386/x86.h | 2 +-
 hw/i386/microvm.c | 2 +-
 hw/i386/pc_piix.c | 7 +++
 hw/i386/pc_q35.c  | 2 +-
 hw/i386/x86.c | 7 +++
 5 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
index 8e306db7bb..4dc30dcb4d 100644
--- a/include/hw/i386/x86.h
+++ b/include/hw/i386/x86.h
@@ -139,7 +139,7 @@ typedef struct GSIState {
 
 qemu_irq x86_allocate_cpu_irq(void);
 void gsi_handler(void *opaque, int n, int level);
-void ioapic_init_gsi(GSIState *gsi_state, const char *parent_name);
+void ioapic_init_gsi(GSIState *gsi_state, Object *parent);
 DeviceState *ioapic_init_secondary(GSIState *gsi_state);
 
 /* pc_sysfw.c */
diff --git a/hw/i386/microvm.c b/hw/i386/microvm.c
index ca55aecc3b..61a772dfe6 100644
--- a/hw/i386/microvm.c
+++ b/hw/i386/microvm.c
@@ -175,7 +175,7 @@ static void microvm_devices_init(MicrovmMachineState *mms)
   _abort);
 isa_bus_register_input_irqs(isa_bus, x86ms->gsi);
 
-ioapic_init_gsi(gsi_state, "machine");
+ioapic_init_gsi(gsi_state, OBJECT(mms));
 if (ioapics > 1) {
 x86ms->ioapic2 = ioapic_init_secondary(gsi_state);
 }
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ec7c07b362..7724396ead 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -107,6 +107,7 @@ static void pc_init1(MachineState *machine,
 X86MachineState *x86ms = X86_MACHINE(machine);
 MemoryRegion *system_memory = get_system_memory();
 MemoryRegion *system_io = get_system_io();
+Object *phb = NULL;
 PCIBus *pci_bus = NULL;
 ISABus *isa_bus;
 Object *piix4_pm = NULL;
@@ -189,8 +190,6 @@ static void pc_init1(MachineState *machine,
 }
 
 if (pcmc->pci_enabled) {
-Object *phb;
-
 pci_memory = g_new(MemoryRegion, 1);
 memory_region_init(pci_memory, NULL, "pci", UINT64_MAX);
 rom_memory = pci_memory;
@@ -303,8 +302,8 @@ static void pc_init1(MachineState *machine,
 pc_i8259_create(isa_bus, gsi_state->i8259_irq);
 }
 
-if (pcmc->pci_enabled) {
-ioapic_init_gsi(gsi_state, "i440fx");
+if (phb) {
+ioapic_init_gsi(gsi_state, phb);
 }
 
 if (tcg_enabled()) {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 53fb3db26d..c89ff63579 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -263,7 +263,7 @@ static void pc_q35_init(MachineState *machine)
 pc_i8259_create(isa_bus, gsi_state->i8259_irq);
 }
 
-ioapic_init_gsi(gsi_state, "q35");
+ioapic_init_gsi(gsi_state, OBJECT(phb));
 
 if (tcg_enabled()) {
 x86_register_ferr_irq(x86ms->gsi[13]);
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 684dce90e9..807e09bcdb 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -640,20 +640,19 @@ void gsi_handler(void *opaque, int n, int level)
 }
 }
 
-void ioapic_init_gsi(GSIState *gsi_state, const char *parent_name)
+void ioapic_init_gsi(GSIState *gsi_state, Object *parent)
 {
 DeviceState *dev;
 SysBusDevice *d;
 unsigned int i;
 
-assert(parent_name);
+assert(parent);
 if (kvm_ioapic_in_kernel()) {
 dev = qdev_new(TYPE_KVM_IOAPIC);
 } else {
 dev = qdev_new(TYPE_IOAPIC);
 }
-object_property_add_child(object_resolve_path(parent_name, NULL),
-  "ioapic", OBJECT(dev));
+object_property_add_child(parent, "ioapic", OBJECT(dev));
 d = SYS_BUS_DEVICE(dev);
 sysbus_realize_and_unref(d, _fatal);
 sysbus_mmio_map(d, 0, IO_APIC_DEFAULT_ADDRESS);
-- 
2.44.0




[PATCH v2 0/6] Simplify initialization of PC machines

2024-02-24 Thread Bernhard Beschow
The series aims to simplify the initialization process of all PC-based machines
by streamlining redundant code.

Since I haven't seen patches on the list so far for folding CMOS data
generation into pc.c, which frees all PC machines from performing this duty
explicitly, I've appended this cleanup as the last two patches.

Testing done:
* `make check`
* `make check-avocado`
* I'm sending this series from within a VM containing these changes.

v2:
* Rebase onto master, leaving only patches 1, 3, and 5
* Patch 2: Rename "bus" attribute to "pcibus" (Phil)
* Patch 4: Spotted while rebasing
* Patch 6: New patch possible after [1]

Best regards,
Bernhard

[1]
https://patchew.org/QEMU/20240221211626.48190-1-phi...@linaro.org/20240221211626
.48190-10-phi...@linaro.org/

Bernhard Beschow (6):
  hw/i386/x86: Let ioapic_init_gsi() take parent as pointer
  hw/i386/pc: Rename "bus" attribute to "pcibus"
  hw/i386/pc_{piix,q35}: Eliminate local pci_bus/pci_host variables
  hw/i386/pc: Remove unneeded class attribute "kvmclock_enabled"
  hw/i386/pc: Populate RTC attribute directly
  hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove
it

 include/hw/i386/pc.h |  5 +
 include/hw/i386/x86.h|  2 +-
 hw/i386/acpi-build.c |  2 +-
 hw/i386/amd_iommu.c  |  2 +-
 hw/i386/intel_iommu.c|  2 +-
 hw/i386/kvm/xen_evtchn.c |  2 +-
 hw/i386/microvm.c|  2 +-
 hw/i386/pc.c | 27 --
 hw/i386/pc_piix.c| 42 +---
 hw/i386/pc_q35.c | 25 ++--
 hw/i386/x86-iommu.c  |  2 +-
 hw/i386/x86.c|  7 +++
 12 files changed, 43 insertions(+), 77 deletions(-)

-- 
2.44.0




[PATCH v2 6/6] hw/i386/pc: Inline pc_cmos_init() into pc_cmos_init_late() and remove it

2024-02-24 Thread Bernhard Beschow
Now that pc_cmos_init() doesn't populate the X86MachineState::rtc attribute any
longer, its duties can be merged into pc_cmos_init_late() which is called within
machine_done notifier. This frees pc_piix and pc_q35 from explicit CMOS
initialization.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h |  2 --
 hw/i386/pc.c | 10 --
 hw/i386/pc_piix.c|  2 --
 hw/i386/pc_q35.c |  2 --
 4 files changed, 16 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 4bb1899602..2b7c53d619 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -178,8 +178,6 @@ void pc_basic_device_init(struct PCMachineState *pcms,
   ISADevice *rtc_state,
   bool create_fdctrl,
   uint32_t hpet_irqs);
-void pc_cmos_init(PCMachineState *pcms,
-  ISADevice *s);
 void pc_nic_init(PCMachineClass *pcmc, ISABus *isa_bus, PCIBus *pci_bus);
 
 void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 880e95de26..fad4c54512 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -567,14 +567,6 @@ static void pc_cmos_init_late(PCMachineState *pcms)
 mc146818rtc_set_cmos_data(s, 0x39, val);
 
 pc_cmos_init_floppy(s, pc_find_fdc0());
-}
-
-void pc_cmos_init(PCMachineState *pcms,
-  ISADevice *rtc)
-{
-int val;
-X86MachineState *x86ms = X86_MACHINE(pcms);
-MC146818RtcState *s = MC146818_RTC(rtc);
 
 /* various important CMOS locations needed by PC/Bochs bios */
 
@@ -617,8 +609,6 @@ void pc_cmos_init(PCMachineState *pcms,
 val |= 0x02; /* FPU is there */
 val |= 0x04; /* PS/2 mouse installed */
 mc146818rtc_set_cmos_data(s, REG_EQUIPMENT_BYTE, val);
-
-/* hard drives and FDC are handled by pc_cmos_init_late() */
 }
 
 static void handle_a20_line_change(void *opaque, int irq, int level)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index ce6aad758d..637f4d38be 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -342,8 +342,6 @@ static void pc_init1(MachineState *machine,
 }
 #endif
 
-pc_cmos_init(pcms, x86ms->rtc);
-
 if (piix4_pm) {
 smi_irq = qemu_allocate_irq(pc_acpi_smi_interrupt, first_cpu, 0);
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index e0b3f55a02..df0a5f934c 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -310,8 +310,6 @@ static void pc_q35_init(MachineState *machine)
 smbus_eeprom_init(pcms->smbus, 8, NULL, 0);
 }
 
-pc_cmos_init(pcms, x86ms->rtc);
-
 /* the rest devices to which pci devfn is automatically assigned */
 pc_vga_init(isa_bus, pcms->pcibus);
 pc_nic_init(pcmc, isa_bus, pcms->pcibus);
-- 
2.44.0




[PATCH v2 4/6] hw/i386/pc: Remove unneeded class attribute "kvmclock_enabled"

2024-02-24 Thread Bernhard Beschow
PCMachineClass introduces the attribute into the class hierarchy and sets it to
true. There is no sub class overriding the attribute. Commit 30d2a17b46e9
"hw/i386: Remove the deprecated machines 0.12 up to 0.15" removed the last
overrides of this attribute. The attribute is now unneeded and can be removed.

Fixes: 30d2a17b46e9 "hw/i386: Remove the deprecated machines 0.12 up to 0.15"
Cc: Thomas Huth 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h | 1 -
 hw/i386/pc.c | 1 -
 hw/i386/pc_piix.c| 2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 27834043c3..4bb1899602 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -92,7 +92,6 @@ struct PCMachineClass {
 
 /* Device configuration: */
 bool pci_enabled;
-bool kvmclock_enabled;
 const char *default_south_bridge;
 
 /* Compat options: */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 353edeb2ea..a80f809b83 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1799,7 +1799,6 @@ static void pc_machine_class_init(ObjectClass *oc, void 
*data)
 pcmc->smbios_uuid_encoded = true;
 pcmc->gigabyte_align = true;
 pcmc->has_reserved_memory = true;
-pcmc->kvmclock_enabled = true;
 pcmc->enforce_aligned_dimm = true;
 pcmc->enforce_amd_1tb_hole = true;
 /* BIOS ACPI tables: 128K. Other BIOS datastructures: less than 4K reported
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 814d24326d..49d5d48db9 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -184,7 +184,7 @@ static void pc_init1(MachineState *machine,
 pc_machine_init_sgx_epc(pcms);
 x86_cpus_init(x86ms, pcmc->default_cpu_version);
 
-if (kvm_enabled() && pcmc->kvmclock_enabled) {
+if (kvm_enabled()) {
 kvmclock_create(pcmc->kvmclock_create_always);
 }
 
-- 
2.44.0




[PATCH v2 2/6] hw/i386/pc: Rename "bus" attribute to "pcibus"

2024-02-24 Thread Bernhard Beschow
The attribute is of type PCIBus; reflect that in the name. It will also make the
next change more intuitive.

Suggested-by: Philippe Mathieu-Daudé 
Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h | 2 +-
 hw/i386/acpi-build.c | 2 +-
 hw/i386/amd_iommu.c  | 2 +-
 hw/i386/intel_iommu.c| 2 +-
 hw/i386/kvm/xen_evtchn.c | 2 +-
 hw/i386/pc.c | 8 
 hw/i386/pc_piix.c| 6 +++---
 hw/i386/pc_q35.c | 2 +-
 hw/i386/x86-iommu.c  | 2 +-
 9 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index e88468131a..27834043c3 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -31,7 +31,7 @@ typedef struct PCMachineState {
 Notifier machine_done;
 
 /* Pointers to devices and objects: */
-PCIBus *bus;
+PCIBus *pcibus;
 I2CBus *smbus;
 PFlashCFI01 *flash[2];
 ISADevice *pcspk;
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index d3ce96dd9f..cd3f2d0148 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1556,7 +1556,7 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
 }
 
 crs_range_set_init(_range_set);
-bus = PC_MACHINE(machine)->bus;
+bus = PC_MACHINE(machine)->pcibus;
 if (bus) {
 QLIST_FOREACH(bus, >child, sibling) {
 uint8_t bus_num = pci_bus_num(bus);
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 7329553ad3..6d4fde72f9 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1584,7 +1584,7 @@ static void amdvi_sysbus_realize(DeviceState *dev, Error 
**errp)
 MachineState *ms = MACHINE(qdev_get_machine());
 PCMachineState *pcms = PC_MACHINE(ms);
 X86MachineState *x86ms = X86_MACHINE(ms);
-PCIBus *bus = pcms->bus;
+PCIBus *bus = pcms->pcibus;
 
 s->iotlb = g_hash_table_new_full(amdvi_uint64_hash,
  amdvi_uint64_equal, g_free, g_free);
diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index cf933189d3..cc8e59674e 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -4183,7 +4183,7 @@ static void vtd_realize(DeviceState *dev, Error **errp)
 MachineState *ms = MACHINE(qdev_get_machine());
 PCMachineState *pcms = PC_MACHINE(ms);
 X86MachineState *x86ms = X86_MACHINE(ms);
-PCIBus *bus = pcms->bus;
+PCIBus *bus = pcms->pcibus;
 IntelIOMMUState *s = INTEL_IOMMU_DEVICE(dev);
 X86IOMMUState *x86_iommu = X86_IOMMU_DEVICE(s);
 
diff --git a/hw/i386/kvm/xen_evtchn.c b/hw/i386/kvm/xen_evtchn.c
index 0171ef6d59..a5052c0ea3 100644
--- a/hw/i386/kvm/xen_evtchn.c
+++ b/hw/i386/kvm/xen_evtchn.c
@@ -371,7 +371,7 @@ static int set_callback_pci_intx(XenEvtchnState *s, 
uint64_t param)
 return 0;
 }
 
-pdev = pci_find_device(pcms->bus, bus, devfn);
+pdev = pci_find_device(pcms->pcibus, bus, devfn);
 if (!pdev) {
 return 0;
 }
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index f8eb684a49..353edeb2ea 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -675,7 +675,7 @@ void pc_machine_done(Notifier *notifier, void *data)
 PCMachineState, machine_done);
 X86MachineState *x86ms = X86_MACHINE(pcms);
 
-cxl_hook_up_pxb_registers(pcms->bus, >cxl_devices_state,
+cxl_hook_up_pxb_registers(pcms->pcibus, >cxl_devices_state,
   _fatal);
 
 if (pcms->cxl_devices_state.is_enabled) {
@@ -685,7 +685,7 @@ void pc_machine_done(Notifier *notifier, void *data)
 /* set the number of CPUs */
 x86_rtc_set_cpus_count(x86ms->rtc, x86ms->boot_cpus);
 
-fw_cfg_add_extra_pci_roots(pcms->bus, x86ms->fw_cfg);
+fw_cfg_add_extra_pci_roots(pcms->pcibus, x86ms->fw_cfg);
 
 acpi_setup();
 if (x86ms->fw_cfg) {
@@ -1250,8 +1250,8 @@ void pc_basic_device_init(struct PCMachineState *pcms,
 xen_evtchn_create(IOAPIC_NUM_PINS, gsi);
 xen_gnttab_create();
 xen_xenstore_create();
-if (pcms->bus) {
-pci_create_simple(pcms->bus, -1, "xen-platform");
+if (pcms->pcibus) {
+pci_create_simple(pcms->pcibus, -1, "xen-platform");
 }
 xen_bus_init();
 xen_be_init();
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 7724396ead..3393b93007 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -216,7 +216,7 @@ static void pc_init1(MachineState *machine,
 pci_bus_map_irqs(pci_bus,
  xen_enabled() ? xen_pci_slot_get_pirq
: pc_pci_slot_get_pirq);
-pcms->bus = pci_bus;
+pcms->pcibus = pci_bus;
 
 hole64_size = object_property_get_uint(phb,
PCI_HOST_PROP_PCI_HOLE64_SIZE,
@@ -480,8 +480,8 @@ static void pc_xen_hvm_init(MachineState *machine)
 }
 
 pc_xen_hvm_init

Re: [PATCH] vl, pc: turn -no-fd-bootchk into a machine property

2024-02-21 Thread Bernhard Beschow



Am 21. Februar 2024 09:04:21 UTC schrieb Paolo Bonzini :
>On Tue, Feb 20, 2024 at 11:43 PM Bernhard Beschow  wrote:
>>
>>
>>
>> Am 20. Februar 2024 15:53:52 UTC schrieb Paolo Bonzini :
>> >Add a fd-bootchk property to PC machine types, so that -no-fd-bootchk
>> >returns an error if the machine does not support booting from floppies
>> >and checking for boot signatures therein.
>> >
>> >Suggested-by: Philippe Mathieu-Daudé 
>> >Signed-off-by: Paolo Bonzini 
>> >---
>> > include/hw/i386/pc.h |  2 +-
>> > hw/i386/pc.c | 30 +-
>> > system/globals.c |  1 -
>> > system/vl.c  |  2 +-
>> > qemu-options.hx  |  2 +-
>> > 5 files changed, 28 insertions(+), 9 deletions(-)
>> >
>> >diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
>> >index 02a0deedd3c..e5382a02e7a 100644
>> >--- a/include/hw/i386/pc.h
>> >+++ b/include/hw/i386/pc.h
>> >@@ -50,6 +50,7 @@ typedef struct PCMachineState {
>> > bool hpet_enabled;
>> > bool i8042_enabled;
>> > bool default_bus_bypass_iommu;
>> >+bool fd_bootchk;
>> > uint64_t max_fw_size;
>> >
>> > /* ACPI Memory hotplug IO base address */
>> >@@ -147,7 +148,6 @@ OBJECT_DECLARE_TYPE(PCMachineState, PCMachineClass, 
>> >PC_MACHINE)
>> > GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
>> >
>> > /* pc.c */
>> >-extern int fd_bootchk;
>> >
>> > void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
>> >
>> >diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>> >index 28194014f82..31f4bb25a3e 100644
>> >--- a/hw/i386/pc.c
>> >+++ b/hw/i386/pc.c
>> >@@ -399,8 +399,8 @@ static int boot_device2nibble(char boot_device)
>> > return 0;
>> > }
>> >
>> >-static void set_boot_dev(MC146818RtcState *s, const char *boot_device,
>> >- Error **errp)
>> >+static void set_boot_dev(PCMachineState *pcms, MC146818RtcState *s,
>> >+ const char *boot_device, Error **errp)
>> > {
>> > #define PC_MAX_BOOT_DEVICES 3
>> > int nbds, bds[3] = { 0, };
>> >@@ -420,12 +420,14 @@ static void set_boot_dev(MC146818RtcState *s, const 
>> >char *boot_device,
>> > }
>> > }
>> > mc146818rtc_set_cmos_data(s, 0x3d, (bds[1] << 4) | bds[0]);
>> >-mc146818rtc_set_cmos_data(s, 0x38, (bds[2] << 4) | (fd_bootchk ? 0x0 : 
>> >0x1));
>> >+mc146818rtc_set_cmos_data(s, 0x38, (bds[2] << 4) | !pcms->fd_bootchk);
>> > }
>> >
>> > static void pc_boot_set(void *opaque, const char *boot_device, Error 
>> > **errp)
>> > {
>> >-set_boot_dev(opaque, boot_device, errp);
>> >+PCMachineState *pcms = PC_MACHINE(current_machine);
>> >+
>> >+set_boot_dev(pcms, opaque, boot_device, errp);
>> > }
>> >
>> > static void pc_cmos_init_floppy(MC146818RtcState *rtc_state, ISADevice 
>> > *floppy)
>> >@@ -617,6 +619,9 @@ void pc_cmos_init(PCMachineState *pcms,
>> > mc146818rtc_set_cmos_data(s, 0x5c, val >> 8);
>> > mc146818rtc_set_cmos_data(s, 0x5d, val >> 16);
>> >
>> >+object_property_add_bool(obj, "fd-bootchk", pc_machine_get_fd_bootchk,
>> >+ pc_machine_set_fd_bootchk);
>>
>> Isn't it possible to turn this into a class property or add the property in 
>> pc_machine_initfn()? Aggregating properties in one place seems more 
>> comprehensible to me.
>
>Sure, I placed it in pc_cmos_init because rtc_state is already created here.

Great! I'll rebase my PC initialization series on top of Peter's reset cleanup 
series which probably results in folding cmos initialization into pc.c.

Best regards,
Bernhard

>
>Paolo
>



Re: [PATCH 02/10] hw/i386/pc: Do pc_cmos_init_late() from pc_machine_done()

2024-02-20 Thread Bernhard Beschow



Am 20. Februar 2024 16:06:14 UTC schrieb Peter Maydell 
:
>In the i386 PC machine, we want to run the pc_cmos_init_late()
>function only once the IDE and floppy drive devices have been set up.
>We currently do this using qemu_register_reset(), and then have the
>function call qemu_unregister_reset() on itself, so it runs exactly
>once.
>
>This was an expedient way to do it back in 2010 when we first added
>this (in commit c0897e0cb94e8), but now we have a more obvious point
>to do "machine initialization that has to happen after generic device
>init": the machine-init-done hook.
>
>Do the pc_cmos_init_late() work from our existing PC machine init
>done hook function, so we can drop the use of qemu_register_reset()
>and qemu_unregister_reset().
>
>Because the pointers to the devices we need (the IDE buses and the
>RTC) are now all in the machine state, we don't need the
>pc_cmos_init_late_arg struct and can just pass the PCMachineState
>pointer.
>
>Signed-off-by: Peter Maydell 
>---
> hw/i386/pc.c | 39 ---
> 1 file changed, 16 insertions(+), 23 deletions(-)
>
>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>index 8b0f54e284c..4c3cfe9fc35 100644
>--- a/hw/i386/pc.c
>+++ b/hw/i386/pc.c
>@@ -465,11 +465,6 @@ static void pc_cmos_init_floppy(MC146818RtcState 
>*rtc_state, ISADevice *floppy)
> mc146818rtc_set_cmos_data(rtc_state, REG_EQUIPMENT_BYTE, val);
> }
> 
>-typedef struct pc_cmos_init_late_arg {
>-MC146818RtcState *rtc_state;
>-BusState *idebus[2];
>-} pc_cmos_init_late_arg;
>-
> typedef struct check_fdc_state {
> ISADevice *floppy;
> bool multiple;
>@@ -530,23 +525,25 @@ static ISADevice *pc_find_fdc0(void)
> return state.floppy;
> }
> 
>-static void pc_cmos_init_late(void *opaque)
>+static void pc_cmos_init_late(PCMachineState *pcms)
> {
>-pc_cmos_init_late_arg *arg = opaque;
>-MC146818RtcState *s = arg->rtc_state;
>+X86MachineState *x86ms = X86_MACHINE(pcms);
>+MC146818RtcState *s = MC146818_RTC(x86ms->rtc);
> int16_t cylinders;
> int8_t heads, sectors;
> int val;
> int i, trans;
> 
> val = 0;
>-if (arg->idebus[0] && ide_get_geometry(arg->idebus[0], 0,
>-   , , ) >= 
>0) {
>+if (pcms->idebus[0] &&
>+ide_get_geometry(pcms->idebus[0], 0,
>+ , , ) >= 0) {
> cmos_init_hd(s, 0x19, 0x1b, cylinders, heads, sectors);
> val |= 0xf0;
> }
>-if (arg->idebus[0] && ide_get_geometry(arg->idebus[0], 1,
>-   , , ) >= 
>0) {
>+if (pcms->idebus[0] &&
>+ide_get_geometry(pcms->idebus[0], 1,
>+ , , ) >= 0) {
> cmos_init_hd(s, 0x1a, 0x24, cylinders, heads, sectors);
> val |= 0x0f;
> }
>@@ -558,10 +555,11 @@ static void pc_cmos_init_late(void *opaque)
>geometry.  It is always such that: 1 <= sects <= 63, 1
><= heads <= 16, 1 <= cylinders <= 16383. The BIOS
>geometry can be different if a translation is done. */
>-if (arg->idebus[i / 2] &&
>-ide_get_geometry(arg->idebus[i / 2], i % 2,
>+BusState *idebus = pcms->idebus[i / 2];
>+if (idebus &&
>+ide_get_geometry(idebus, i % 2,
>  , , ) >= 0) {
>-trans = ide_get_bios_chs_trans(arg->idebus[i / 2], i % 2) - 1;
>+trans = ide_get_bios_chs_trans(idebus, i % 2) - 1;
> assert((trans & ~3) == 0);
> val |= trans << (i * 2);
> }
>@@ -569,15 +567,12 @@ static void pc_cmos_init_late(void *opaque)
> mc146818rtc_set_cmos_data(s, 0x39, val);
> 
> pc_cmos_init_floppy(s, pc_find_fdc0());
>-
>-qemu_unregister_reset(pc_cmos_init_late, opaque);
> }
> 
> void pc_cmos_init(PCMachineState *pcms,
>   ISADevice *rtc)
> {
> int val;
>-static pc_cmos_init_late_arg arg;
> X86MachineState *x86ms = X86_MACHINE(pcms);
> MC146818RtcState *s = MC146818_RTC(rtc);
> 
>@@ -631,11 +626,7 @@ void pc_cmos_init(PCMachineState *pcms,
> val |= 0x04; /* PS/2 mouse installed */
> mc146818rtc_set_cmos_data(s, REG_EQUIPMENT_BYTE, val);
> 
>-/* hard drives and FDC */
>-arg.rtc_state = s;
>-arg.idebus[0] = pcms->idebus[0];
>-arg.idebus[1] = pcms->idebus[1];
>-qemu_register_reset(pc_cmos_init_late, );
>+/* hard drives and FDC are handled by pc_cmos_init_late() */
> }
> 
> static void handle_a20_line_change(void *opaque, int irq, int level)
>@@ -703,6 +694,8 @@ void pc_machine_done(Notifier *notifier, void *data)
> /* update FW_CFG_NB_CPUS to account for -device added CPUs */
> fw_cfg_modify_i16(x86ms->fw_cfg, FW_CFG_NB_CPUS, x86ms->boot_cpus);
> }
>+
>+pc_cmos_init_late(pcms);

Nice. With 
https://patchew.org/QEMU/20240208220349.4948-1-shen...@gmail.com/20240208220349.4948-9-shen...@gmail.com/
 on top it might be possible to merge pc_cmos_init_late() and pc_cmos_init(), 
thus 

Re: [PATCH] vl, pc: turn -no-fd-bootchk into a machine property

2024-02-20 Thread Bernhard Beschow



Am 20. Februar 2024 15:53:52 UTC schrieb Paolo Bonzini :
>Add a fd-bootchk property to PC machine types, so that -no-fd-bootchk
>returns an error if the machine does not support booting from floppies
>and checking for boot signatures therein.
>
>Suggested-by: Philippe Mathieu-Daudé 
>Signed-off-by: Paolo Bonzini 
>---
> include/hw/i386/pc.h |  2 +-
> hw/i386/pc.c | 30 +-
> system/globals.c |  1 -
> system/vl.c  |  2 +-
> qemu-options.hx  |  2 +-
> 5 files changed, 28 insertions(+), 9 deletions(-)
>
>diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
>index 02a0deedd3c..e5382a02e7a 100644
>--- a/include/hw/i386/pc.h
>+++ b/include/hw/i386/pc.h
>@@ -50,6 +50,7 @@ typedef struct PCMachineState {
> bool hpet_enabled;
> bool i8042_enabled;
> bool default_bus_bypass_iommu;
>+bool fd_bootchk;
> uint64_t max_fw_size;
> 
> /* ACPI Memory hotplug IO base address */
>@@ -147,7 +148,6 @@ OBJECT_DECLARE_TYPE(PCMachineState, PCMachineClass, 
>PC_MACHINE)
> GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled);
> 
> /* pc.c */
>-extern int fd_bootchk;
> 
> void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
> 
>diff --git a/hw/i386/pc.c b/hw/i386/pc.c
>index 28194014f82..31f4bb25a3e 100644
>--- a/hw/i386/pc.c
>+++ b/hw/i386/pc.c
>@@ -399,8 +399,8 @@ static int boot_device2nibble(char boot_device)
> return 0;
> }
> 
>-static void set_boot_dev(MC146818RtcState *s, const char *boot_device,
>- Error **errp)
>+static void set_boot_dev(PCMachineState *pcms, MC146818RtcState *s,
>+ const char *boot_device, Error **errp)
> {
> #define PC_MAX_BOOT_DEVICES 3
> int nbds, bds[3] = { 0, };
>@@ -420,12 +420,14 @@ static void set_boot_dev(MC146818RtcState *s, const char 
>*boot_device,
> }
> }
> mc146818rtc_set_cmos_data(s, 0x3d, (bds[1] << 4) | bds[0]);
>-mc146818rtc_set_cmos_data(s, 0x38, (bds[2] << 4) | (fd_bootchk ? 0x0 : 
>0x1));
>+mc146818rtc_set_cmos_data(s, 0x38, (bds[2] << 4) | !pcms->fd_bootchk);
> }
> 
> static void pc_boot_set(void *opaque, const char *boot_device, Error **errp)
> {
>-set_boot_dev(opaque, boot_device, errp);
>+PCMachineState *pcms = PC_MACHINE(current_machine);
>+
>+set_boot_dev(pcms, opaque, boot_device, errp);
> }
> 
> static void pc_cmos_init_floppy(MC146818RtcState *rtc_state, ISADevice 
> *floppy)
>@@ -617,6 +619,9 @@ void pc_cmos_init(PCMachineState *pcms,
> mc146818rtc_set_cmos_data(s, 0x5c, val >> 8);
> mc146818rtc_set_cmos_data(s, 0x5d, val >> 16);
> 
>+object_property_add_bool(obj, "fd-bootchk", pc_machine_get_fd_bootchk,
>+ pc_machine_set_fd_bootchk);

Isn't it possible to turn this into a class property or add the property in 
pc_machine_initfn()? Aggregating properties in one place seems more 
comprehensible to me.

Note that I've submitted a series attempting to simplify initialization of the 
PC machines which still waits for reviews: 
https://patchew.org/QEMU/20240208220349.4948-1-shen...@gmail.com/

Thanks,
Bernhard

>+
> object_property_add_link(OBJECT(pcms), "rtc_state",
>  TYPE_ISA_DEVICE,
>  (Object **)>rtc,
>@@ -625,7 +630,7 @@ void pc_cmos_init(PCMachineState *pcms,
> object_property_set_link(OBJECT(pcms), "rtc_state", OBJECT(s),
>  _abort);
> 
>-set_boot_dev(s, MACHINE(pcms)->boot_config.order, _fatal);
>+set_boot_dev(pcms, s, MACHINE(pcms)->boot_config.order, _fatal);
> 
> val = 0;
> val |= 0x02; /* FPU is there */
>@@ -1559,6 +1564,20 @@ static void pc_machine_set_vmport(Object *obj, Visitor 
>*v, const char *name,
> visit_type_OnOffAuto(v, name, >vmport, errp);
> }
> 
>+static bool pc_machine_get_fd_bootchk(Object *obj, Error **errp)
>+{
>+PCMachineState *pcms = PC_MACHINE(obj);
>+
>+return pcms->fd_bootchk;
>+}
>+
>+static void pc_machine_set_fd_bootchk(Object *obj, bool value, Error **errp)
>+{
>+PCMachineState *pcms = PC_MACHINE(obj);
>+
>+pcms->fd_bootchk = value;
>+}
>+
> static bool pc_machine_get_smbus(Object *obj, Error **errp)
> {
> PCMachineState *pcms = PC_MACHINE(obj);
>@@ -1747,6 +1766,7 @@ static void pc_machine_initfn(Object *obj)
> #ifdef CONFIG_HPET
> pcms->hpet_enabled = true;
> #endif
>+pcms->fd_bootchk = true;
> pcms->default_bus_bypass_iommu = false;
> 
> pc_system_flash_create(pcms);
>diff --git a/system/globals.c b/system/globals.c
>index b6d4e72530e..5d0046ba105 100644
>--- a/system/globals.c
>+++ b/system/globals.c
>@@ -41,7 +41,6 @@ int vga_interface_type = VGA_NONE;
> bool vga_interface_created;
> Chardev *parallel_hds[MAX_PARALLEL_PORTS];
> int win2k_install_hack;
>-int fd_bootchk = 1;
> int graphic_rotate;
> QEMUOptionRom option_rom[MAX_OPTION_ROMS];
> int nb_option_roms;
>diff --git a/system/vl.c b/system/vl.c
>index a82555ae155..4627004304b 100644
>--- a/system/vl.c
>+++ 

Re: [PATCH 06/14] hw/pci-bridge: Extract QOM ICH definitions to 'ich_dmi_pci.h'

2024-02-20 Thread Bernhard Beschow



Am 19. Februar 2024 16:38:46 UTC schrieb "Philippe Mathieu-Daudé" 
:
>Expose TYPE_ICH_DMI_PCI_BRIDGE to the new
>"hw/pci-bridge/ich_dmi_pci.h" header.
>
>Signed-off-by: Philippe Mathieu-Daudé 
>---
> MAINTAINERS |  1 +
> include/hw/pci-bridge/ich_dmi_pci.h | 20 
> include/hw/southbridge/ich9.h   |  2 --
> hw/pci-bridge/i82801b11.c   | 11 ---
> 4 files changed, 25 insertions(+), 9 deletions(-)
> create mode 100644 include/hw/pci-bridge/ich_dmi_pci.h
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 1b210c5cc1..50507c3dd6 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -2609,6 +2609,7 @@ F: hw/acpi/ich9*.c
> F: hw/i2c/smbus_ich9.c
> F: hw/isa/lpc_ich9.c
> F: include/hw/acpi/ich9*.h
>+F: include/hw/pci-bridge/ich_dmi_pci.h
> F: include/hw/southbridge/ich9.h
> 
> PIIX4 South Bridge (i82371AB)
>diff --git a/include/hw/pci-bridge/ich_dmi_pci.h 
>b/include/hw/pci-bridge/ich_dmi_pci.h
>new file mode 100644
>index 00..7623b32b8e
>--- /dev/null
>+++ b/include/hw/pci-bridge/ich_dmi_pci.h

Shouldn't we name the new header like its source file, i.e. i82801b11.h?

>@@ -0,0 +1,20 @@
>+/*
>+ * QEMU ICH4 i82801b11 dmi-to-pci Bridge Emulation
>+ *
>+ * SPDX-License-Identifier: GPL-2.0-or-later
>+ */
>+
>+#ifndef HW_PCI_BRIDGE_ICH_D2P_H
>+#define HW_PCI_BRIDGE_ICH_D2P_H
>+
>+#include "qom/object.h"
>+#include "hw/pci/pci_bridge.h"
>+
>+#define TYPE_ICH_DMI_PCI_BRIDGE "i82801b11-bridge"
>+OBJECT_DECLARE_SIMPLE_TYPE(I82801b11Bridge, ICH_DMI_PCI_BRIDGE)
>+
>+struct I82801b11Bridge {
>+PCIBridge parent_obj;
>+};
>+
>+#endif
>diff --git a/include/hw/southbridge/ich9.h b/include/hw/southbridge/ich9.h
>index bee522a4cf..b2abf483e0 100644
>--- a/include/hw/southbridge/ich9.h
>+++ b/include/hw/southbridge/ich9.h
>@@ -114,8 +114,6 @@ struct ICH9LPCState {
> 
> #define ICH9_D2P_SECONDARY_DEFAULT  (256 - 8)
> 
>-#define ICH9_D2P_A2_REVISION0x92
>-
> /* D31:F0 LPC Processor Interface */
> #define ICH9_RST_CNT_IOPORT 0xCF9
> 
>diff --git a/hw/pci-bridge/i82801b11.c b/hw/pci-bridge/i82801b11.c
>index c140919cbc..dd17e35b0a 100644
>--- a/hw/pci-bridge/i82801b11.c
>+++ b/hw/pci-bridge/i82801b11.c
>@@ -45,7 +45,7 @@
> #include "hw/pci/pci_bridge.h"
> #include "migration/vmstate.h"
> #include "qemu/module.h"
>-#include "hw/southbridge/ich9.h"
>+#include "hw/pci-bridge/ich_dmi_pci.h"
> 
> /*/
> /* ICH9 DMI-to-PCI bridge */
>@@ -53,11 +53,8 @@
> #define I82801ba_SSVID_SVID 0
> #define I82801ba_SSVID_SSID 0
> 
>-typedef struct I82801b11Bridge {
>-/*< private >*/
>-PCIBridge parent_obj;
>-/*< public >*/
>-} I82801b11Bridge;
>+
>+#define ICH9_D2P_A2_REVISION0x92
> 
> static void i82801b11_bridge_realize(PCIDevice *d, Error **errp)
> {
>@@ -103,7 +100,7 @@ static void i82801b11_bridge_class_init(ObjectClass 
>*klass, void *data)
> }
> 
> static const TypeInfo i82801b11_bridge_info = {
>-.name  = "i82801b11-bridge",
>+.name  = TYPE_ICH_DMI_PCI_BRIDGE,
> .parent= TYPE_PCI_BRIDGE,
> .instance_size = sizeof(I82801b11Bridge),
> .class_init= i82801b11_bridge_class_init,



Re: [PATCH v2] docs/system/ppc: Document running Linux on AmigaNG machines

2024-02-20 Thread Bernhard Beschow



Am 19. Februar 2024 20:30:06 UTC schrieb BALATON Zoltan :
>Documentation on how to run Linux on the amigaone, pegasos2 and
>sam460ex machines is currently buried in the depths of the qemu-devel
>mailing list and in the source code. Let's collect the information in
>the QEMU handbook for a one stop solution.
>
>Co-authored-by: Bernhard Beschow 
>Signed-off-by: BALATON Zoltan 
>---
>v2:
>Move top level title one level up so subsections will be below it in TOC
>
> MAINTAINERS |   1 +
> docs/system/ppc/amigang.rst | 161 
> docs/system/target-ppc.rst  |   1 +
> 3 files changed, 163 insertions(+)
> create mode 100644 docs/system/ppc/amigang.rst
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 7d61fb9319..0aef8cb2a6 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -1562,6 +1562,7 @@ F: hw/rtc/m41t80.c
> F: pc-bios/canyonlands.dt[sb]
> F: pc-bios/u-boot-sam460ex-20100605.bin
> F: roms/u-boot-sam460ex
>+F: docs/system/ppc/amigang.rst
> 
> pegasos2
> M: BALATON Zoltan 
>diff --git a/docs/system/ppc/amigang.rst b/docs/system/ppc/amigang.rst
>new file mode 100644
>index 00..738decd0c5
>--- /dev/null
>+++ b/docs/system/ppc/amigang.rst
>@@ -0,0 +1,161 @@
>+=
>+AmigaNG boards (``amigaone``, ``pegasos2``, ``sam460ex``)
>+=
>+
>+These PowerPC machines emulate boards that are primarily used for
>+running Amiga like OSes (AmigaOS 4, MorphOS and AROS) but these can
>+also run Linux which is what this section documents.
>+
>+Eyetech AmigaOne/Mai Logic Teron (``amigaone``)
>+===
>+
>+The ``amigaone`` machine emulates an AmigaOne XE mainboard by Eyetech
>+which is a rebranded Mai Logic Teron board with modified U-Boot
>+firmware to support AmigaOS 4.
>+
>+Emulated devices
>+
>+
>+ * PowerPC 7457 CPU (can also use``-cpu g3, 750cxe, 750fx`` or ``750gx``)
>+ * Articia S north bridge
>+ * VIA VT82C686B south bridge
>+ * PCI VGA compatible card (guests may need other card instead)
>+ * PS/2 keyboard and mouse
>+
>+Firmware
>+
>+
>+A firmware binary is necessary for the boot process. It is a modified
>+U-Boot under GPL but its source is lost so it cannot be included in
>+QEMU. A binary is available at
>+https://www.hyperion-entertainment.com/index.php/downloads?view=files=28.
>+The ROM image is in the last 512kB which can be extracted with the
>+following command:
>+
>+.. code-block:: bash
>+
>+  $ tail -c 524288 updater.image > u-boot-amigaone.bin
>+
>+The BIOS emulator in the firmware is unable to run QEMU‘s standard
>+vgabios so ``VGABIOS-lgpl-latest.bin`` is needed instead which can be
>+downloaded from http://www.nongnu.org/vgabios.
>+
>+Running Linux
>+-
>+
>+There are some Linux images under the following link that work on the
>+``amigaone`` machine:
>+https://sourceforge.net/projects/amigaone-linux/files/debian-installer/.
>+To boot the system run:
>+
>+.. code-block:: bash
>+
>+  $ qemu-system-ppc -machine amigaone -bios u-boot-amigaone.bin \
>+-cdrom "A1 Linux Net Installer.iso" \
>+-device 
>ati-vga,model=rv100,romfile=VGABIOS-lgpl-latest.bin
>+
>+From the firmware menu that appears select ``Boot sequence`` →
>+``Amiga Multiboot Options`` and set ``Boot device 1`` to
>+``Onboard VIA IDE CDROM``. Then hit escape until the main screen appears 
>again,
>+hit escape once more and from the exit menu that appears select either
>+``Save settings and exit`` or ``Use settings for this session only``. It may
>+take a long time loading the kernel into memory but eventually it boots and 
>the
>+installer becomes visible. The ``ati-vga`` RV100 emulation is not
>+complete yet so only frame buffer works, DRM and 3D is not available.
>+
>+Genesi/bPlan Pegasos II (``pegasos2``)
>+==
>+
>+The ``pegasos2`` machine emulates the Pegasos II sold by Genesi and
>+designed by bPlan. Its schematics are available at
>+https://www.powerdeveloper.org/platforms/pegasos/schematics

Period missing at end of sentence.

>+
>+Emulated devices
>+
>+
>+ * PowerPC 7457 CPU (can also use``-cpu g3`` or ``750cxe``)
>+ * Marvell MV64361 Discovery II north bridge
>+ * VIA VT8231 south bridge
>+ * PCI VGA compatible card (guests may need other card instead)
>+ * PS/2 keyboard and mouse
>+
>+Firmware
>+
>+
>+The Pegasos II board has an Open Firmware compliant ROM based on
>+SmartFirmware but it has some changes that are n

Re: [PATCH 0/5] Implement port 92 in south bridges

2024-02-19 Thread Bernhard Beschow



Am 18. Februar 2024 16:12:30 UTC schrieb BALATON Zoltan :
>On Sun, 18 Feb 2024, Bernhard Beschow wrote:
>> This series attempts to make QEMU's south bridge families PIIX, ICH9, and VIA
>> 82xx more self-contained by integrating IO port 92 like the originals do.
>> 
>> In QEMU, the IO port is currently instantiated as a dedicated device in 
>> common
>> PC code. While this works and even results in less code, it seems cleaner to
>> model the behavior of the real devices. For example, software running on the
>> Malta machine, which uses PIIX4, needs to take port 92 into account, even if 
>> it
>> doesn't use it (does it?). Moreover, the FDC37M81x used in the original Malta
>> machine provides a port 92 too, which can be activated. If QEMU implemented 
>> the
>> FDC37M81x more closely, one could check if Yamon (or any alternative boot
>> loader) deals correctly with these ports.
>
>Maybe that's unlikely as this register is for controlling A20 line of Intel 
>CPUs so probably there's no use for it in a MIPS or PPC board but I'm not sure 
>if it may be used for something else.
>
>> Moving port 92 into the south bridges might also help with 
>> configuration-driven
>> machine creation. In such a scenario it is probably desirable if machine code
>> had less of its own idea of which devices it creates.
>
>The direction is probably good as these chips have a pin for A20 control and 
>handle the register themselves but I'm not sure this series is the right way. 
>One immediate problem is that TYPE_PORT92 has state which is in the migration 
>stream so moving it elsewhere would break migration which would need to be 
>handled. Does this series handle that?

I've created two migration streams, one before and one after the change. Then 
I've converted both to JSON with `analyze-migration.py -d desc`. The only 
difference is the position of the port92 record in the devices array (before: 
31, after: 14). I'm no migration expert, but telling from the JSON content, 
"name" and "instance_id" seem to uniquely identify a device record and changing 
positions in an array seems rather innocent to me. Since there will be one 
port92 record before and after this series, it seems as if migration is not 
affected. But someone's judgment with migration expertise may be needed here.

> I'm not sure it's worth the effort though if it results in more comlex code. 
> If the migration issue is handled, then I think we should get rid of 
> TYPE_PORT92 completely and just add the one reg and qemu_irq modeling the 
> output pin as qemu_gpio to the south bridge implementations directly, not 
> embedding a separate object for it as these south bridges may already have 
> some io region for ports and state where the reg can be stored so it could be 
> added there instead of just moving the TYPE_PORT92 there.

I'd rather avoid adding copy'n'paste code. Having port 92 wrapped in a 
dedicated, reusable device model which handles migration seems like the way to 
go to me.

> But with the migration issue it's probably easier to just leave it as it is 
> now. Even if this would model the real chip better, it would result in more 
> code and complexity in QEMU so not sure it's a good idea because of that.
>
>> Moving port 92 from
>> machine code into a potentially user-creaeable device (where it is part of 
>> per
>> datasheet) seems like a good direction. Of course, machine code still wires 
>> up
>> port 92 and I don't have a good idea on how to make this user-configurable.
>> Such insights might provide some input for discussions around
>> configuration-driven machine creation.
>
>That's a generic problem for dynamic or declarative machine creation to solve. 
>Likely the machine description will also need to describe the connections 
>between devices, not just what devices to instantiate. So that's not specific 
>to port92. As we're not there yet it's also not urgent to touch this port92 
>stuff.
>
>Maybe I overestimate the migration issue as I'm not familiar with that so if 
>others think it's not an issue then I'm not against this series as it would 
>bring the model closer to the actual hardware but then go all the way and get 
>rid of TYPE_PORT92 and just implement it in the south bridges. But due to how 
>it's currently done and how that's now baked in because of backward 
>compatibility requrement for migration, I'm not sure it would really simplify 
>the code, so we may need to live with what we have now. But let me know if I'm 
>wrong and missed something.
>
>Regards,
>BALATON Zoltan

Any other opinions?

Best regards,
Bernhard

>
>> This series is structured as follows: Patch 1 moves TYPE_PORT92 into the isa
>> directory to m

Re: [PATCH] hw/i386/pc_q35: Populate interrupt handlers before realizing LPC PCI function

2024-02-19 Thread Bernhard Beschow



Am 19. Februar 2024 08:51:07 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 17/2/24 11:46, Bernhard Beschow wrote:
>> The interrupt handlers need to be populated before the device is realized 
>> since
>> internal devices such as the RTC are wired during realize(). If the interrupt
>> handlers aren't populated, devices such as the RTC will be wired with a NULL
>> interrupt handler, i.e. MC146818RtcState::irq is NULL.
>> 
>> Fixes: fc11ca08bc29 "hw/i386/q35: Realize LPC PCI function before accessing 
>> it"
>
>I think this commit is correct, but exposes a pre-existing bug.
>
>I noticed it for the PC equivalent, so didn't posted the
>pci_realize_and_unref() change there, but missed the Q35 is
>similarly affected.
>
>IMO the problem is how the GSI lines are allocated. The ISA
>ones are allocated twice!
>
>Before this patch, the 1st alloc is just overwritten and
>ignored, ISA RTC IRQ is assigned to the 2nd alloc.
>
>After this patch, ISA RTC IRQ is assigned to the 1st alloc,
>then the 2nd alloc wipe it, and an empty IRQ is eventually
>wired later.
>
>The proper fix is to alloc ISA IRQs just once. Either filling
>GSI with them, or having GSI take care of that.
>
>Since GSI is not a piece of HW but a concept to simplify
>developers writing x86 HW drivers, I currently think we shouldn't
>model it as a QOM container.

The qdev_connect_gpio_out_named() call below populates an internal array of 
IOAPIC_NUM_PINS callbacks inside the LPC device. These callbacks trigger IRQs. 
The RTC inside the LPC device relies on this array to be populated with valid 
handlers during LPC's realize, else the RTC gets wired with no/invalid 
callbacks. This patch fixes this array to be populated before realize. Before 
this patch, the array was populated after LPC's realize, causing NULL callbacks 
to be assigned to the RTC there.

Thus, IRQ allocations don't seem like the underlying problem to me.

The general pattern I see here is that qdev_connect_gpio_out_*() should be 
performed *before* realizing the device passed as the first argument. The 
reason is that this device could contain an arbitrarily deep nesting of 
internal devices which may want to be assigned valid IRQ callbacks during its 
realize. AFAICS this pattern would work recursively, so internal devices which 
have themselves internal devices would be wired correctly. This pattern may not 
be immediately evident since most of the time we're wiring "leaf" devices which 
can be wired either way.

Furthermore, it seems that qdev_get_gpio_in_*() may need to be called *after* a 
device's realize because the device may need to prepare its IRQs before 
exposing them. So it looks like qdev_get_gpio_in_*() and qdev_get_gpio_out_*() 
should be treated in dual manner.

Note that "IRQ forwarders" like piix_request_i8259_irq() may allow 
qdev_connect_gpio_out_*() to be called after a device has been realized. This 
pattern comes with a small performance penalty and might add some cognitive 
load when trying to understand code. So the above pattern seems like the 
preferable solution.

Best regards,
Bernhard

>
>> Cc: Philippe Mathieu-Daudé 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   hw/i386/pc_q35.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>> index d346fa3b1d..43675bf597 100644
>> --- a/hw/i386/pc_q35.c
>> +++ b/hw/i386/pc_q35.c
>> @@ -240,10 +240,10 @@ static void pc_q35_init(MachineState *machine)
>>   lpc_dev = DEVICE(lpc);
>>   qdev_prop_set_bit(lpc_dev, "smm-enabled",
>> x86_machine_is_smm_enabled(x86ms));
>> -pci_realize_and_unref(lpc, host_bus, _fatal);
>>   for (i = 0; i < IOAPIC_NUM_PINS; i++) {
>>   qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i, 
>> x86ms->gsi[i]);
>>   }
>> +pci_realize_and_unref(lpc, host_bus, _fatal);
>> rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(lpc), 
>> "rtc"));
>>   
>



[PATCH 4/5] hw/i386/pc: Inline i8042_setup_a20_line() and remove it

2024-02-18 Thread Bernhard Beschow
This function is used once in the pc machines. Remove it since it contains one
line only.

Signed-off-by: Bernhard Beschow 
---
 include/hw/input/i8042.h | 1 -
 hw/i386/pc.c | 2 +-
 hw/input/pckbd.c | 5 -
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/include/hw/input/i8042.h b/include/hw/input/i8042.h
index 9fb3f8d787..e90f008b66 100644
--- a/include/hw/input/i8042.h
+++ b/include/hw/input/i8042.h
@@ -89,7 +89,6 @@ struct MMIOKBDState {
 
 
 void i8042_isa_mouse_fake_event(ISAKBDState *isa);
-void i8042_setup_a20_line(ISADevice *dev, qemu_irq a20_out);
 
 static inline bool i8042_present(void)
 {
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 8b601ea6cf..1b2077dc32 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1195,7 +1195,7 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl,
 }
 
 a20_line = qemu_allocate_irqs(handle_a20_line_change, first_cpu, 1);
-i8042_setup_a20_line(i8042, a20_line[0]);
+qdev_connect_gpio_out_named(DEVICE(i8042), I8042_A20_LINE, 0, a20_line[0]);
 g_free(a20_line);
 }
 
diff --git a/hw/input/pckbd.c b/hw/input/pckbd.c
index 90a4d9eb40..74f10b640f 100644
--- a/hw/input/pckbd.c
+++ b/hw/input/pckbd.c
@@ -777,11 +777,6 @@ void i8042_isa_mouse_fake_event(ISAKBDState *isa)
 ps2_mouse_fake_event(>ps2mouse);
 }
 
-void i8042_setup_a20_line(ISADevice *dev, qemu_irq a20_out)
-{
-qdev_connect_gpio_out_named(DEVICE(dev), I8042_A20_LINE, 0, a20_out);
-}
-
 static const VMStateDescription vmstate_kbd_isa = {
 .name = "pckbd",
 .version_id = 3,
-- 
2.43.2




[PATCH 3/5] hw/isa: Embed TYPE_PORT92 in south bridges used in PC machines

2024-02-18 Thread Bernhard Beschow
Port 92 is an integral part of the PIIX and ICH south bridges, so instantiate it
there. The isapc machine now needs to instantiate it explicitly, analoguous to
the RTC.

Note that due to migration compatibility, port92 is optional in the south
bridges. It is always instantiated the isapc machine for simplicity.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h  |  2 +-
 include/hw/southbridge/ich9.h |  4 
 include/hw/southbridge/piix.h |  3 +++
 hw/i386/pc.c  | 18 --
 hw/i386/pc_piix.c |  9 +++--
 hw/i386/pc_q35.c  |  8 +---
 hw/isa/lpc_ich9.c |  9 +
 hw/isa/piix.c |  9 +
 hw/isa/Kconfig|  2 ++
 9 files changed, 52 insertions(+), 12 deletions(-)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index b2987209b1..a9ff1f5ab3 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -178,7 +178,7 @@ uint64_t pc_pci_hole64_start(void);
 DeviceState *pc_vga_init(ISABus *isa_bus, PCIBus *pci_bus);
 void pc_basic_device_init(struct PCMachineState *pcms,
   ISABus *isa_bus, qemu_irq *gsi,
-  ISADevice *rtc_state,
+  ISADevice *rtc_state, ISADevice *port92,
   bool create_fdctrl,
   uint32_t hpet_irqs);
 void pc_cmos_init(PCMachineState *pcms,
diff --git a/include/hw/southbridge/ich9.h b/include/hw/southbridge/ich9.h
index fd01649d04..d70a94f5e7 100644
--- a/include/hw/southbridge/ich9.h
+++ b/include/hw/southbridge/ich9.h
@@ -3,6 +3,7 @@
 
 #include "hw/isa/apm.h"
 #include "hw/acpi/ich9.h"
+#include "hw/isa/port92.h"
 #include "hw/intc/ioapic.h"
 #include "hw/pci/pci.h"
 #include "hw/pci/pci_device.h"
@@ -32,6 +33,7 @@ struct ICH9LPCState {
 uint8_t irr[PCI_SLOT_MAX][PCI_NUM_PINS];
 
 MC146818RtcState rtc;
+Port92State port92;
 APMState apm;
 ICH9LPCPMRegs pm;
 uint32_t sci_level; /* track sci level */
@@ -54,6 +56,8 @@ struct ICH9LPCState {
 uint8_t rst_cnt;
 MemoryRegion rst_cnt_mem;
 
+bool has_port92;
+
 /* SMI feature negotiation via fw_cfg */
 uint64_t smi_host_features;   /* guest-invisible, host endian */
 uint8_t smi_host_features_le[8];  /* guest-visible, read-only, little
diff --git a/include/hw/southbridge/piix.h b/include/hw/southbridge/piix.h
index 86709ba2e4..35058529d1 100644
--- a/include/hw/southbridge/piix.h
+++ b/include/hw/southbridge/piix.h
@@ -15,6 +15,7 @@
 #include "hw/pci/pci_device.h"
 #include "hw/acpi/piix4.h"
 #include "hw/ide/pci.h"
+#include "hw/isa/port92.h"
 #include "hw/rtc/mc146818rtc.h"
 #include "hw/usb/hcd-uhci.h"
 
@@ -56,6 +57,7 @@ struct PIIXState {
 int32_t pci_irq_levels_vmstate[PIIX_NUM_PIRQS];
 
 MC146818RtcState rtc;
+Port92State port92;
 PCIIDEState ide;
 UHCIState uhci;
 PIIX4PMState pm;
@@ -71,6 +73,7 @@ struct PIIXState {
 bool has_acpi;
 bool has_pic;
 bool has_pit;
+bool has_port92;
 bool has_usb;
 bool smm_enabled;
 };
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 0b11d4576e..8b601ea6cf 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -1160,7 +1160,7 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl,
 int i;
 DriveInfo *fd[MAX_FD];
 qemu_irq *a20_line;
-ISADevice *fdc, *i8042, *port92, *vmmouse;
+ISADevice *fdc, *i8042, *vmmouse;
 
 serial_hds_isa_init(isa_bus, 0, MAX_ISA_SERIAL_PORTS);
 parallel_hds_isa_init(isa_bus, MAX_PARALLEL_PORTS);
@@ -1193,18 +1193,15 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl,
  _abort);
 isa_realize_and_unref(vmmouse, isa_bus, _fatal);
 }
-port92 = isa_create_simple(isa_bus, TYPE_PORT92);
 
-a20_line = qemu_allocate_irqs(handle_a20_line_change, first_cpu, 2);
+a20_line = qemu_allocate_irqs(handle_a20_line_change, first_cpu, 1);
 i8042_setup_a20_line(i8042, a20_line[0]);
-qdev_connect_gpio_out_named(DEVICE(port92),
-PORT92_A20_LINE, 0, a20_line[1]);
 g_free(a20_line);
 }
 
 void pc_basic_device_init(struct PCMachineState *pcms,
   ISABus *isa_bus, qemu_irq *gsi,
-  ISADevice *rtc_state,
+  ISADevice *rtc_state, ISADevice *port92,
   bool create_fdctrl,
   uint32_t hpet_irqs)
 {
@@ -1296,6 +1293,15 @@ void pc_basic_device_init(struct PCMachineState *pcms,
 /* Super I/O */
 pc_superio_init(isa_bus, create_fdctrl, pcms->i8042_enabled,
 pcms->vmport != ON_OFF_AUTO_ON);
+
+if (port92) {
+qemu_irq *a20_line;
+
+a20_line = qemu_allocate_irqs(handle_a20_line_change, first_cpu, 1);
+qdev_connect_

[PATCH 2/5] hw/i386/port92: Allow for TYPE_PORT92 to be embedded in devices

2024-02-18 Thread Bernhard Beschow
Port 92 is an integral part of south bridges. Allow for embedding it there.

South bridges aren't architecture-specific, so move port92.c to hw/isa which is
accessible to other architectures than x86.

Signed-off-by: Bernhard Beschow 
---
 include/hw/i386/pc.h  |  5 -
 include/hw/isa/port92.h   | 30 ++
 hw/i386/pc.c  |  1 +
 hw/{i386 => isa}/port92.c | 14 +-
 hw/i386/Kconfig   |  1 +
 hw/i386/meson.build   |  3 +--
 hw/i386/trace-events  |  4 
 hw/isa/Kconfig|  3 +++
 hw/isa/meson.build|  1 +
 hw/isa/trace-events   |  4 
 10 files changed, 42 insertions(+), 24 deletions(-)
 create mode 100644 include/hw/isa/port92.h
 rename hw/{i386 => isa}/port92.c (91%)

diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index ec0e5efcb2..b2987209b1 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -188,11 +188,6 @@ void pc_nic_init(PCMachineClass *pcmc, ISABus *isa_bus, 
PCIBus *pci_bus);
 
 void pc_i8259_create(ISABus *isa_bus, qemu_irq *i8259_irqs);
 
-/* port92.c */
-#define PORT92_A20_LINE "a20"
-
-#define TYPE_PORT92 "port92"
-
 /* pc_sysfw.c */
 void pc_system_flash_create(PCMachineState *pcms);
 void pc_system_flash_cleanup_unused(PCMachineState *pcms);
diff --git a/include/hw/isa/port92.h b/include/hw/isa/port92.h
new file mode 100644
index 00..214783d071
--- /dev/null
+++ b/include/hw/isa/port92.h
@@ -0,0 +1,30 @@
+/*
+ * QEMU I/O port 0x92 (System Control Port A, to handle Fast Gate A20)
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ *
+ * SPDX-License-Identifier: MIT
+ */
+
+#ifndef HW_PORT92_H
+#define HW_PORT92_H
+
+#include "exec/memory.h"
+#include "hw/irq.h"
+#include "hw/isa/isa.h"
+#include "qom/object.h"
+
+#define TYPE_PORT92 "port92"
+OBJECT_DECLARE_SIMPLE_TYPE(Port92State, PORT92)
+
+struct Port92State {
+ISADevice parent_obj;
+
+MemoryRegion io;
+uint8_t outport;
+qemu_irq a20_out;
+};
+
+#define PORT92_A20_LINE "a20"
+
+#endif /* HW_PORT92_H */
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 196827531a..0b11d4576e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -32,6 +32,7 @@
 #include "hw/i386/vmport.h"
 #include "sysemu/cpus.h"
 #include "hw/ide/internal.h"
+#include "hw/isa/port92.h"
 #include "hw/timer/hpet.h"
 #include "hw/loader.h"
 #include "hw/rtc/mc146818rtc.h"
diff --git a/hw/i386/port92.c b/hw/isa/port92.c
similarity index 91%
rename from hw/i386/port92.c
rename to hw/isa/port92.c
index 1070bfbf36..06df06b088 100644
--- a/hw/i386/port92.c
+++ b/hw/isa/port92.c
@@ -9,20 +9,8 @@
 #include "qemu/osdep.h"
 #include "sysemu/runstate.h"
 #include "migration/vmstate.h"
-#include "hw/irq.h"
-#include "hw/i386/pc.h"
+#include "hw/isa/port92.h"
 #include "trace.h"
-#include "qom/object.h"
-
-OBJECT_DECLARE_SIMPLE_TYPE(Port92State, PORT92)
-
-struct Port92State {
-ISADevice parent_obj;
-
-MemoryRegion io;
-uint8_t outport;
-qemu_irq a20_out;
-};
 
 static void port92_write(void *opaque, hwaddr addr, uint64_t val,
  unsigned size)
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index a1846be6f7..ccf6de4a00 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -37,6 +37,7 @@ config PC
 select I8254
 select PCKBD
 select PCSPK
+select PORT92
 select I8257
 select MC146818RTC
 # For ACPI builder:
diff --git a/hw/i386/meson.build b/hw/i386/meson.build
index b9c1ca39cb..94d558edd6 100644
--- a/hw/i386/meson.build
+++ b/hw/i386/meson.build
@@ -24,8 +24,7 @@ i386_ss.add(when: 'CONFIG_ACPI', if_true: 
files('acpi-common.c'))
 i386_ss.add(when: 'CONFIG_PC', if_true: files(
   'pc.c',
   'pc_sysfw.c',
-  'acpi-build.c',
-  'port92.c'))
+  'acpi-build.c'))
 i386_ss.add(when: 'CONFIG_X86_FW_OVMF', if_true: files('pc_sysfw_ovmf.c'),
 if_false: 
files('pc_sysfw_ovmf-stubs.c'))
 
diff --git a/hw/i386/trace-events b/hw/i386/trace-events
index 53c02d7ac8..b730589394 100644
--- a/hw/i386/trace-events
+++ b/hw/i386/trace-events
@@ -118,10 +118,6 @@ vmport_command(unsigned char command) "command: 0x%02x"
 x86_gsi_interrupt(int irqn, int level) "GSI interrupt #%d level:%d"
 x86_pic_interrupt(int irqn, int level) "PIC interrupt #%d level:%d"
 
-# port92.c
-port92_read(uint8_t val) "port92: read 0x%02x"
-port92_write(uint8_t val) "port92: write 0x%02x"
-
 # vmmouse.c
 vmmouse_get_status(void) ""
 vmmouse_mouse_event(int x, int y, int dz, int buttons_state) "event: x=%d y=%d 
dz=%d state=%d"
diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index 73c6470805..efdf43e92c 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -49,6 +49,9 @@ config PIIX
 select MC1

[PATCH 1/5] hw/isa/meson.build: Sort alphabetically

2024-02-18 Thread Bernhard Beschow
Fixes: fbd758008f0f "hw/isa: extract FDC37M81X to a separate file"

Signed-off-by: Bernhard Beschow 
---
 hw/isa/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/isa/meson.build b/hw/isa/meson.build
index f650b39507..3219282217 100644
--- a/hw/isa/meson.build
+++ b/hw/isa/meson.build
@@ -1,10 +1,10 @@
 system_ss.add(when: 'CONFIG_APM', if_true: files('apm.c'))
+system_ss.add(when: 'CONFIG_FDC37M81X', if_true: files('fdc37m81x-superio.c'))
 system_ss.add(when: 'CONFIG_I82378', if_true: files('i82378.c'))
 system_ss.add(when: 'CONFIG_ISA_BUS', if_true: files('isa-bus.c'))
 system_ss.add(when: 'CONFIG_ISA_SUPERIO', if_true: files('isa-superio.c'))
 system_ss.add(when: 'CONFIG_PC87312', if_true: files('pc87312.c'))
 system_ss.add(when: 'CONFIG_PIIX', if_true: files('piix.c'))
-system_ss.add(when: 'CONFIG_FDC37M81X', if_true: files('fdc37m81x-superio.c'))
 system_ss.add(when: 'CONFIG_SMC37C669', if_true: files('smc37c669-superio.c'))
 system_ss.add(when: 'CONFIG_VT82C686', if_true: files('vt82c686.c'))
 
-- 
2.43.2




[PATCH 0/5] Implement port 92 in south bridges

2024-02-18 Thread Bernhard Beschow
This series attempts to make QEMU's south bridge families PIIX, ICH9, and VIA
82xx more self-contained by integrating IO port 92 like the originals do.

In QEMU, the IO port is currently instantiated as a dedicated device in common
PC code. While this works and even results in less code, it seems cleaner to
model the behavior of the real devices. For example, software running on the
Malta machine, which uses PIIX4, needs to take port 92 into account, even if it
doesn't use it (does it?). Moreover, the FDC37M81x used in the original Malta
machine provides a port 92 too, which can be activated. If QEMU implemented the
FDC37M81x more closely, one could check if Yamon (or any alternative boot
loader) deals correctly with these ports.

Moving port 92 into the south bridges might also help with configuration-driven
machine creation. In such a scenario it is probably desirable if machine code
had less of its own idea of which devices it creates. Moving port 92 from
machine code into a potentially user-creaeable device (where it is part of per
datasheet) seems like a good direction. Of course, machine code still wires up
port 92 and I don't have a good idea on how to make this user-configurable.
Such insights might provide some input for discussions around
configuration-driven machine creation.

This series is structured as follows: Patch 1 moves TYPE_PORT92 into the isa
directory to make it reusable by other architectures. It also adds a
configuration switch. Patch 2 integrates TYPE_PORT92 into the PC south bridges
and adapts PC code accordingly. While at it, patch 3 cleans up wiring of the
A20 line with the keyboard controller. Patch 4 simply adds TYPE_PORT92 to the
VIA south bridges which is also needed when using the VIA south bridges in the
pc machine.

Testing done:
* `qemu-system-x86_64 -M {q35,pc},i8042={true,false} ...`
  -> `info mtree` confirms port92 to be present iff i8042=true
* `make check`
* `make check-avocado`
* Start amigaone and pegasos2 machines as described in
https://patchew.org/QEMU/20240216001019.69a524e6...@zero.eik.bme.hu/
  -> no regressions compared to master

Best regards,
Bernhard

Bernhard Beschow (5):
  hw/isa/meson.build: Sort alphabetically
  hw/i386/port92: Allow for TYPE_PORT92 to be embedded in devices
  hw/isa: Embed TYPE_PORT92 in south bridges used in PC machines
  hw/i386/pc: Inline i8042_setup_a20_line() and remove it
  hw/isa/vt82c686: Embed TYPE_PORT92

 include/hw/i386/pc.h  |  7 +--
 include/hw/input/i8042.h  |  1 -
 include/hw/isa/port92.h   | 30 ++
 include/hw/southbridge/ich9.h |  4 
 include/hw/southbridge/piix.h |  3 +++
 hw/i386/pc.c  | 21 ++---
 hw/i386/pc_piix.c |  9 +++--
 hw/i386/pc_q35.c  |  8 +---
 hw/input/pckbd.c  |  5 -
 hw/isa/lpc_ich9.c |  9 +
 hw/isa/piix.c |  9 +
 hw/{i386 => isa}/port92.c | 14 +-
 hw/isa/vt82c686.c |  7 +++
 hw/i386/Kconfig   |  1 +
 hw/i386/meson.build   |  3 +--
 hw/i386/trace-events  |  4 
 hw/isa/Kconfig|  6 ++
 hw/isa/meson.build|  3 ++-
 hw/isa/trace-events   |  4 
 19 files changed, 104 insertions(+), 44 deletions(-)
 create mode 100644 include/hw/isa/port92.h
 rename hw/{i386 => isa}/port92.c (91%)

-- 
2.43.2




[PATCH 5/5] hw/isa/vt82c686: Embed TYPE_PORT92

2024-02-18 Thread Bernhard Beschow
Port 92 is an integral part of the south bridge, so instantiate it there.

Signed-off-by: Bernhard Beschow 
---
 hw/isa/vt82c686.c | 7 +++
 hw/isa/Kconfig| 1 +
 2 files changed, 8 insertions(+)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index aa91942745..c7b96b3133 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -22,6 +22,7 @@
 #include "hw/qdev-properties.h"
 #include "hw/ide/pci.h"
 #include "hw/isa/isa.h"
+#include "hw/isa/port92.h"
 #include "hw/isa/superio.h"
 #include "hw/intc/i8259.h"
 #include "hw/irq.h"
@@ -597,6 +598,7 @@ struct ViaISAState {
 uint16_t irq_state[ISA_NUM_IRQS];
 ViaSuperIOState via_sio;
 MC146818RtcState rtc;
+Port92State port92;
 PCIIDEState ide;
 UHCIState uhci[2];
 ViaPMState pm;
@@ -619,6 +621,7 @@ static void via_isa_init(Object *obj)
 ViaISAState *s = VIA_ISA(obj);
 
 object_initialize_child(obj, "rtc", >rtc, TYPE_MC146818_RTC);
+object_initialize_child(obj, "port92", >port92, TYPE_PORT92);
 object_initialize_child(obj, "ide", >ide, TYPE_VIA_IDE);
 object_initialize_child(obj, "uhci1", >uhci[0], 
TYPE_VT82C686B_USB_UHCI);
 object_initialize_child(obj, "uhci2", >uhci[1], 
TYPE_VT82C686B_USB_UHCI);
@@ -740,6 +743,10 @@ static void via_isa_realize(PCIDevice *d, Error **errp)
 }
 isa_connect_gpio_out(ISA_DEVICE(>rtc), 0, s->rtc.isairq);
 
+if (!qdev_realize(DEVICE(>port92), BUS(isa_bus), errp)) {
+return;
+}
+
 for (i = 0; i < PCI_CONFIG_HEADER_SIZE; i++) {
 if (i < PCI_COMMAND || i >= PCI_REVISION_ID) {
 d->wmask[i] = 0;
diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
index f42a087c07..d94f58a2c1 100644
--- a/hw/isa/Kconfig
+++ b/hw/isa/Kconfig
@@ -66,6 +66,7 @@ config VT82C686
 select I8259
 select IDE_VIA
 select MC146818RTC
+select PORT92
 
 config SMC37C669
 bool
-- 
2.43.2




Re: [PATCH] hw/i386/pc_q35: Populate interrupt handlers before realizing LPC PCI function

2024-02-18 Thread Bernhard Beschow



Am 18. Februar 2024 10:47:26 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 17/2/24 11:46, Bernhard Beschow wrote:
>> The interrupt handlers need to be populated before the device is realized 
>> since
>> internal devices such as the RTC are wired during realize(). If the interrupt
>> handlers aren't populated, devices such as the RTC will be wired with a NULL
>> interrupt handler, i.e. MC146818RtcState::irq is NULL.
>
>Why no CI test caught that?

Good question. I think the missing IRQ connection would even be hardly 
noticeable when running a full and modern graphical Linux distro as guest. 
There is rtc-test.c but I don't know if wiring is in its scope.

Best regards,
Bernhard

>
>> Fixes: fc11ca08bc29 "hw/i386/q35: Realize LPC PCI function before accessing 
>> it"
>> 
>> Cc: Philippe Mathieu-Daudé 
>> Signed-off-by: Bernhard Beschow 
>> ---
>>   hw/i386/pc_q35.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
>> index d346fa3b1d..43675bf597 100644
>> --- a/hw/i386/pc_q35.c
>> +++ b/hw/i386/pc_q35.c
>> @@ -240,10 +240,10 @@ static void pc_q35_init(MachineState *machine)
>>   lpc_dev = DEVICE(lpc);
>>   qdev_prop_set_bit(lpc_dev, "smm-enabled",
>> x86_machine_is_smm_enabled(x86ms));
>> -pci_realize_and_unref(lpc, host_bus, _fatal);
>>   for (i = 0; i < IOAPIC_NUM_PINS; i++) {
>>   qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i, 
>> x86ms->gsi[i]);
>>   }
>> +pci_realize_and_unref(lpc, host_bus, _fatal);
>> rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(lpc), 
>> "rtc"));
>>   
>



[PATCH] hw/i386/pc_q35: Populate interrupt handlers before realizing LPC PCI function

2024-02-17 Thread Bernhard Beschow
The interrupt handlers need to be populated before the device is realized since
internal devices such as the RTC are wired during realize(). If the interrupt
handlers aren't populated, devices such as the RTC will be wired with a NULL
interrupt handler, i.e. MC146818RtcState::irq is NULL.

Fixes: fc11ca08bc29 "hw/i386/q35: Realize LPC PCI function before accessing it"

Cc: Philippe Mathieu-Daudé 
Signed-off-by: Bernhard Beschow 
---
 hw/i386/pc_q35.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d346fa3b1d..43675bf597 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -240,10 +240,10 @@ static void pc_q35_init(MachineState *machine)
 lpc_dev = DEVICE(lpc);
 qdev_prop_set_bit(lpc_dev, "smm-enabled",
   x86_machine_is_smm_enabled(x86ms));
-pci_realize_and_unref(lpc, host_bus, _fatal);
 for (i = 0; i < IOAPIC_NUM_PINS; i++) {
 qdev_connect_gpio_out_named(lpc_dev, ICH9_GPIO_GSI, i, x86ms->gsi[i]);
 }
+pci_realize_and_unref(lpc, host_bus, _fatal);
 
 rtc_state = ISA_DEVICE(object_resolve_path_component(OBJECT(lpc), "rtc"));
 
-- 
2.43.2




Re: [PATCH 0/7] hw/i386: Cleanups around 'hw/i386/pc.h'

2024-02-15 Thread Bernhard Beschow



Am 13. Februar 2024 16:00:26 UTC schrieb "Philippe Mathieu-Daudé" 
:
>On 13/2/24 16:55, Michael S. Tsirkin wrote:
>> On Tue, Feb 13, 2024 at 01:01:45PM +0100, Philippe Mathieu-Daudé wrote:
>>> Trivial patches removing uses of "hw/i386/pc.h".
>> 
>> How did you test that it's indeed unused?
>
>I put and #error in hw/i386/pc.h and built :)
>(I'm trying to remove the PC dependency on generic devices.)
>
>The few generic devices left are not as trivial.
>
>>> Philippe Mathieu-Daudé (7):
>>>target/i386/monitor: Remove unused 'hw/i386/pc.h' header
>>>hw/timer: Move HPET_INTCAP definition to "hpet.h"
>>>hw/isa/lpc_ich9: Remove unused 'hw/i386/pc.h'
>>>hw/i386/acpi: Declare pc_madt_cpu_entry() in 'acpi-common.h'
>>>hw/i386/port92: Add missing 'hw/isa/isa.h' header
>>>hw/acpi/cpu_hotplug: Include 'pci_device.h' instead of 'pci.h'
>>>hw/acpi/cpu_hotplug: Include 'x86.h' instead of 'pc.h'
>>> 
>>>   hw/i386/acpi-common.h   | 3 +++
>>>   include/hw/i386/pc.h| 6 --
>>>   include/hw/timer/hpet.h | 2 ++
>>>   hw/acpi/cpu_hotplug.c   | 4 ++--
>>>   hw/i386/acpi-common.c   | 1 -
>>>   hw/i386/port92.c| 1 +

I'd take care of port92 and make it part of all our three south bridge families 
(which models the real hardware more closely).

Best regards,
Bernhard

>>>   hw/isa/lpc_ich9.c   | 1 -
>>>   hw/timer/hpet.c | 1 -
>>>   target/i386/monitor.c   | 1 -
>>>   9 files changed, 8 insertions(+), 12 deletions(-)
>>> 
>>> -- 
>>> 2.41.0
>> 
>



Re: [PATCH v3 6/9] isa: extract FDC37M81X to a separate file

2024-02-13 Thread Bernhard Beschow



Am 13. Februar 2024 15:50:01 UTC schrieb Paolo Bonzini :
>isa-superio.c currently defines a SuperIO chip that is not used
>by any other user of the file.  Extract the chip to a separate file.
>
>Reviewed-by: BALATON Zoltan 

I think in v2 Zoltan only pointed out a typo in the commit message (which is 
now fixed) but didn't add an R-b tag so far.

Best regards,
Bernhard

>Reviewed-by: Bernhard Beschow 
>Signed-off-by: Paolo Bonzini 
>---
> hw/isa/fdc37m81x-superio.c | 32 
> hw/isa/isa-superio.c   | 18 --
> hw/isa/Kconfig |  4 
> hw/isa/meson.build |  1 +
> hw/mips/Kconfig|  2 +-
> 5 files changed, 38 insertions(+), 19 deletions(-)
> create mode 100644 hw/isa/fdc37m81x-superio.c
>
>diff --git a/hw/isa/fdc37m81x-superio.c b/hw/isa/fdc37m81x-superio.c
>new file mode 100644
>index 000..55e91fbca17
>--- /dev/null
>+++ b/hw/isa/fdc37m81x-superio.c
>@@ -0,0 +1,32 @@
>+/*
>+ * SMS FDC37M817 Super I/O
>+ *
>+ * Copyright (c) 2018 Philippe Mathieu-Daudé
>+ *
>+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
>+ * See the COPYING file in the top-level directory.
>+ * SPDX-License-Identifier: GPL-2.0-or-later
>+ */
>+
>+#include "qemu/osdep.h"
>+#include "hw/isa/superio.h"
>+
>+static void fdc37m81x_class_init(ObjectClass *klass, void *data)
>+{
>+ISASuperIOClass *sc = ISA_SUPERIO_CLASS(klass);
>+
>+sc->serial.count = 2; /* NS16C550A */
>+sc->parallel.count = 1;
>+sc->floppy.count = 1; /* SMSC 82077AA Compatible */
>+sc->ide.count = 0;
>+}
>+
>+static const TypeInfo types[] = {
>+{
>+.name  = TYPE_FDC37M81X_SUPERIO,
>+.parent= TYPE_ISA_SUPERIO,
>+.class_init= fdc37m81x_class_init,
>+},
>+};
>+
>+DEFINE_TYPES(types)
>diff --git a/hw/isa/isa-superio.c b/hw/isa/isa-superio.c
>index 98d50844f71..a8c8c58ef7f 100644
>--- a/hw/isa/isa-superio.c
>+++ b/hw/isa/isa-superio.c
>@@ -190,27 +190,9 @@ static const TypeInfo isa_superio_type_info = {
> .instance_size = sizeof(ISASuperIODevice),
> };
> 
>-/* SMS FDC37M817 Super I/O */
>-static void fdc37m81x_class_init(ObjectClass *klass, void *data)
>-{
>-ISASuperIOClass *sc = ISA_SUPERIO_CLASS(klass);
>-
>-sc->serial.count = 2; /* NS16C550A */
>-sc->parallel.count = 1;
>-sc->floppy.count = 1; /* SMSC 82077AA Compatible */
>-sc->ide.count = 0;
>-}
>-
>-static const TypeInfo fdc37m81x_type_info = {
>-.name  = TYPE_FDC37M81X_SUPERIO,
>-.parent= TYPE_ISA_SUPERIO,
>-.class_init= fdc37m81x_class_init,
>-};
>-
> static void isa_superio_register_types(void)
> {
> type_register_static(_superio_type_info);
>-type_register_static(_type_info);
> }
> 
> type_init(isa_superio_register_types)
>diff --git a/hw/isa/Kconfig b/hw/isa/Kconfig
>index 5df3c09cd51..73c6470805c 100644
>--- a/hw/isa/Kconfig
>+++ b/hw/isa/Kconfig
>@@ -23,6 +23,10 @@ config ISA_SUPERIO
> # Some users of ISA_SUPERIO do not use it
> #select IDE_ISA
> 
>+config FDC37M81X
>+bool
>+select ISA_SUPERIO
>+
> config PC87312
> bool
> select ISA_SUPERIO
>diff --git a/hw/isa/meson.build b/hw/isa/meson.build
>index 2ab99ce0c6b..f650b395071 100644
>--- a/hw/isa/meson.build
>+++ b/hw/isa/meson.build
>@@ -4,6 +4,7 @@ system_ss.add(when: 'CONFIG_ISA_BUS', if_true: 
>files('isa-bus.c'))
> system_ss.add(when: 'CONFIG_ISA_SUPERIO', if_true: files('isa-superio.c'))
> system_ss.add(when: 'CONFIG_PC87312', if_true: files('pc87312.c'))
> system_ss.add(when: 'CONFIG_PIIX', if_true: files('piix.c'))
>+system_ss.add(when: 'CONFIG_FDC37M81X', if_true: files('fdc37m81x-superio.c'))
> system_ss.add(when: 'CONFIG_SMC37C669', if_true: files('smc37c669-superio.c'))
> system_ss.add(when: 'CONFIG_VT82C686', if_true: files('vt82c686.c'))
> 
>diff --git a/hw/mips/Kconfig b/hw/mips/Kconfig
>index afcfb2b8eca..e57db4f6412 100644
>--- a/hw/mips/Kconfig
>+++ b/hw/mips/Kconfig
>@@ -1,7 +1,7 @@
> config MALTA
> bool
>+select FDC37M81X
> select GT64120
>-select ISA_SUPERIO
> select PIIX
> 
> config MIPSSIM



  1   2   3   4   5   6   7   8   9   10   >