Re: [RESEND][PATCH v3 0/7] Add ivshmem-flat device

[Alex Bennée]

Markus Armbruster <armbru@redhat.com> writes:

> Gustavo Romero <gustavo.romero@linaro.org> writes:
>
>> This is a resend of the series:
>>
>> https://lore.kernel.org/qemu-devel/20240222222218.2261956-1-gustavo.romero@linaro.org/
>>
>> rebased on the current master. The series was sent about 9 months ago and
>> remains relevant. Besides addressing the longstanding issue:
>>
>> https://gitlab.com/qemu-project/qemu/-/issues/1134
>>
>> it has generated interest in the community at least twice since its last
>> version, from different contexts:
>>
>> https://lists.nongnu.org/archive/html/qemu-discuss/2024-05/msg00003.html
>> https://lists.nongnu.org/archive/html/qemu-devel/2024-09/msg00374.html
>>
>> This suggests the series is being used out-of-tree in various contexts, such
>> as experiments with heterogeneous architectures.
>>
>> But due to the fact it relies on sysbus, which is marked for future removal,
>> some maintainers objected to accepting the patchset, causing it to be held in
>> the ML.
>
> Actually, I inquired about the use cases, and was told it's for OpenAMP.
> I challenged the use of ivshmem for that purpose in some detail[*], but
> got no reply.
>
>>         However, given the ongoing community interest and since currently 
>> there
>> isn't a better way on QEMU than using sysbus for the wiring needs of this
>> device (e.g. to wire the device to a CPU IRQ input line), I'd kindly like to 
>> ask
>> maintainers to reconsider its acceptance.
>
> [*] https://lore.kernel.org/qemu-devel/87zfth4psf.fsf@pond.sub.org/

Yes the principle use case is modelling asymmetric set ups with two sets
of CPU cores attached only by a piece of shared RAM with maybe a
signalling an IRQ. As the CPUs are doing the work we want to test both
sides (VirtIO device and driver) rather than provide an emulation.

Once we have a single QEMU binary that is dynamically configurable and
supports heterogeneous setups then we can model it within QEMU itself.
However until that point 2 QEMU's and some shared memory is the easiest
way to test such things.

This is currently being worked on as part of the larger HVAC project:

  https://linaro.atlassian.net/wiki/spaces/HVAC/overview

where we are working on a new VirtIO transport layer (virtio-msg) that
doesn't have the issues associated with lack of trapped configuration
space.

>
> [...]

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro