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

[Alistair Francis]

On Sat, Jun 30, 2018 at 5:53 AM, Peter Maydell <address@hidden> wrote:
> 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.

Ok, I'm sending an updated PR now. I can't reproduce the failure for
some reason so hopefully I have fixed the problem by not modifying the
virtio include.

Alistair

>
> thanks
> -- PMM