Re: [Qemu-devel] [PULL v2 0/7] riscv-pull queue

[Peter Maydell]

On 29 June 2018 at 18:22, Alistair Francis <address@hidden> wrote:
> The following changes since commit 75507f1aba6feb73ae43329922d51571550b9128:
>
>   Merge remote-tracking branch 'remotes/berrange/tags/min-glib-pull-request' 
> into staging (2018-06-29 15:04:20 +0100)
>
> are available in the Git repository at:
>
>   address@hidden:alistair23/qemu.git tags/pull-riscv-pull-20180629
>
> for you to fetch changes up to e4847c96685e210649e6ec90fecd732a744dad75:
>
>   hw/riscv/sifive_u: Connect the Cadence GEM Ethernet device (2018-06-29 
> 09:51:05 -0700)
>
> ----------------------------------------------------------------
> RISC-V: SoCify SiFive boards and connect GEM
>
> This series has three tasks:
>  1. To convert the SiFive U and E machines into SoCs and boards
>  2. To connect the Cadence GEM device to the SiFive U board
>  3. Fix some device tree problems with the SiFive U board
>
> After this series the SiFive E and U boards have their SoCs split into
> seperate QEMU objects, which can be used on future boards if desired.
>
> The RISC-V Virt and Spike boards have not been converted. They haven't
> been converted as they aren't physical boards, so it doesn't make a
> whole lot of sense to split them into an SoC and board. The only
> disadvantage with this is that they now differ to the SiFive boards.
>
> This series also connect the Cadence GEM device to the SiFive U board.
> There are some interrupt line changes requried before this is possible.

Hi; this fails to build I'm afraid:

  LINK    riscv32-softmmu/qemu-system-riscv32
../fsdev/qemu-fsdev.o:(.data.rel.ro+0x8): undefined reference to `local_ops'
../fsdev/qemu-fsdev.o:(.data.rel.ro+0x18): undefined reference to `handle_ops'
../fsdev/qemu-fsdev.o:(.data.rel.ro+0x28): undefined reference to `synth_ops'
../fsdev/qemu-fsdev.o:(.data.rel.ro+0x38): undefined reference to `proxy_ops'

I'm not sure exactly what's going on here but I suspect
commit e4847c96685, which made the riscv default-config
files stop including virtio.mak.

I think the bit of code that defines these _ops structs and the
bit of code that's using them aren't guarded by exactly the same
set of CONFIG_* defines. That inconsistency is arguably a bug,
but nobody notices it because you just use virtio.mak to get all
the virtio defines.

The definitions are guarded by "CONFIG_VIRTIO_9P || CONFIG_XEN"
but the use by "CONFIG_VIRTFS && (CONFIG_VIRTIO || CONFIG_XEN)",
so if you define CONFIG_VIRTIO without CONFIG_VIRTIO_9P you're
going to run into this.

The guard on the definitions was only added in commit b5dfdb082fc350f3,
so you've had an unfortunate race with that pullreq I think.

All that said, it looks to me like e4847c98 should not have been
changing how the virtio configs are set -- the commit message
doesn't say anything about it -- so the simplest thing is just to
fix that up.

thanks
-- PMM