Question on preferred location for QEMU sample projects

Question on preferred location for QEMU sample projects

[Ruslan Ruslichenko]

Hi everyone,

We are currently preparing the v2 patch series for the Remote-Port
Co-simulation protocol for interfacing with SystemC modules. The first
revision was here:
https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg01760.html.

As part of this submission, we would like to publish a sample project
serving as a demonstration of how to connect a QEMU Remote-Port
frontend to a SystemC backend.

The sample project implements a standard SystemC IP core and uses
several external components such as:
- libsystemctlm-soc: https://github.com/Xilinx/libsystemctlm-soc
- VCML Library: https://github.com/machineware-gmbh/vcml
- SystemC Library: https://github.com/accellera-official/systemc

We have a question regarding the location for this kind of project.
Could you please suggest if there is a preferred location or some
standard practice for hosting such a sample project?

--
BR,
Ruslan

Re: Question on preferred location for QEMU sample projects

[Markus Armbruster]

Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:

> Hi everyone,
>
> We are currently preparing the v2 patch series for the Remote-Port
> Co-simulation protocol for interfacing with SystemC modules. The first
> revision was here:
> https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg01760.html.
>
> As part of this submission, we would like to publish a sample project
> serving as a demonstration of how to connect a QEMU Remote-Port
> frontend to a SystemC backend.
>
> The sample project implements a standard SystemC IP core and uses
> several external components such as:
> - libsystemctlm-soc: https://github.com/Xilinx/libsystemctlm-soc
> - VCML Library: https://github.com/machineware-gmbh/vcml
> - SystemC Library: https://github.com/accellera-official/systemc
>
> We have a question regarding the location for this kind of project.
> Could you please suggest if there is a preferred location or some
> standard practice for hosting such a sample project?

Location within the QEMU source tree?

Re: Question on preferred location for QEMU sample projects

[Ruslan Ruslichenko]

On Mon, Apr 13, 2026 at 9:25 AM Markus Armbruster <armbru@redhat.com> wrote:
>
> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>
> > Hi everyone,
> >
> > We are currently preparing the v2 patch series for the Remote-Port
> > Co-simulation protocol for interfacing with SystemC modules. The first
> > revision was here:
> > https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg01760.html.
> >
> > As part of this submission, we would like to publish a sample project
> > serving as a demonstration of how to connect a QEMU Remote-Port
> > frontend to a SystemC backend.
> >
> > The sample project implements a standard SystemC IP core and uses
> > several external components such as:
> > - libsystemctlm-soc: https://github.com/Xilinx/libsystemctlm-soc
> > - VCML Library: https://github.com/machineware-gmbh/vcml
> > - SystemC Library: https://github.com/accellera-official/systemc
> >
> > We have a question regarding the location for this kind of project.
> > Could you please suggest if there is a preferred location or some
> > standard practice for hosting such a sample project?
>
> Location within the QEMU source tree?
>

Hello Markus,

Yes, it would be good to include this project within the QEMU source tree.
To build the project, the mentioned SystemC, libsystemctlm-soc and
VCML libraries and their specific dependencies need to be built and
installed separately.
Would this approach be acceptable?

Alternatively, is there an auxiliary repository within the QEMU
infrastructure that is better suited for these types of sample
projects,
perhaps somewhere under https://gitlab.com/qemu-project?

--
BR,
Ruslan

Re: Question on preferred location for QEMU sample projects

[Ruslan Ruslichenko]

On Mon, Apr 13, 2026 at 4:04 PM Ruslan Ruslichenko
<ruslichenko.r@gmail.com> wrote:
>
> On Mon, Apr 13, 2026 at 9:25 AM Markus Armbruster <armbru@redhat.com> wrote:
> >
> > Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
> >
> > > Hi everyone,
> > >
> > > We are currently preparing the v2 patch series for the Remote-Port
> > > Co-simulation protocol for interfacing with SystemC modules. The first
> > > revision was here:
> > > https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg01760.html.
> > >
> > > As part of this submission, we would like to publish a sample project
> > > serving as a demonstration of how to connect a QEMU Remote-Port
> > > frontend to a SystemC backend.
> > >
> > > The sample project implements a standard SystemC IP core and uses
> > > several external components such as:
> > > - libsystemctlm-soc: https://github.com/Xilinx/libsystemctlm-soc
> > > - VCML Library: https://github.com/machineware-gmbh/vcml
> > > - SystemC Library: https://github.com/accellera-official/systemc
> > >
> > > We have a question regarding the location for this kind of project.
> > > Could you please suggest if there is a preferred location or some
> > > standard practice for hosting such a sample project?
> >
> > Location within the QEMU source tree?
> >
>
> Hello Markus,
>
> Yes, it would be good to include this project within the QEMU source tree.
> To build the project, the mentioned SystemC, libsystemctlm-soc and
> VCML libraries and their specific dependencies need to be built and
> installed separately.
> Would this approach be acceptable?
>
> Alternatively, is there an auxiliary repository within the QEMU
> infrastructure that is better suited for these types of sample
> projects,
> perhaps somewhere under https://gitlab.com/qemu-project?
>
> --
> BR,
> Ruslan

Hello Markus,

Do you have any thoughts on the preferred location for this sample project?

Best regards,
Ruslan

Re: Question on preferred location for QEMU sample projects

[Markus Armbruster]

Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:

> On Mon, Apr 13, 2026 at 4:04 PM Ruslan Ruslichenko
> <ruslichenko.r@gmail.com> wrote:
>>
>> On Mon, Apr 13, 2026 at 9:25 AM Markus Armbruster <armbru@redhat.com> wrote:
>> >
>> > Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>> >
>> > > Hi everyone,
>> > >
>> > > We are currently preparing the v2 patch series for the Remote-Port
>> > > Co-simulation protocol for interfacing with SystemC modules. The first
>> > > revision was here:
>> > > https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg01760.html.
>> > >
>> > > As part of this submission, we would like to publish a sample project
>> > > serving as a demonstration of how to connect a QEMU Remote-Port
>> > > frontend to a SystemC backend.
>> > >
>> > > The sample project implements a standard SystemC IP core and uses
>> > > several external components such as:
>> > > - libsystemctlm-soc: https://github.com/Xilinx/libsystemctlm-soc
>> > > - VCML Library: https://github.com/machineware-gmbh/vcml
>> > > - SystemC Library: https://github.com/accellera-official/systemc
>> > >
>> > > We have a question regarding the location for this kind of project.
>> > > Could you please suggest if there is a preferred location or some
>> > > standard practice for hosting such a sample project?
>> >
>> > Location within the QEMU source tree?
>> >
>>
>> Hello Markus,
>>
>> Yes, it would be good to include this project within the QEMU source tree.
>> To build the project, the mentioned SystemC, libsystemctlm-soc and
>> VCML libraries and their specific dependencies need to be built and
>> installed separately.
>> Would this approach be acceptable?

We have a few (small) examples under contrib/.  However, Peter (cc'ed)
has been trying to clean out that directory.

>>
>> Alternatively, is there an auxiliary repository within the QEMU
>> infrastructure that is better suited for these types of sample
>> projects,
>> perhaps somewhere under https://gitlab.com/qemu-project?
>>
>> --
>> BR,
>> Ruslan
>
> Hello Markus,
>
> Do you have any thoughts on the preferred location for this sample project?
>
> Best regards,
> Ruslan

Peter, what about you?

Re: Question on preferred location for QEMU sample projects

[Daniel P. Berrangé]

On Wed, Apr 29, 2026 at 09:25:21PM +0200, Ruslan Ruslichenko wrote:
> On Mon, Apr 13, 2026 at 4:04 PM Ruslan Ruslichenko
> <ruslichenko.r@gmail.com> wrote:
> >
> > On Mon, Apr 13, 2026 at 9:25 AM Markus Armbruster <armbru@redhat.com> wrote:
> > >
> > > Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
> > >
> > > > Hi everyone,
> > > >
> > > > We are currently preparing the v2 patch series for the Remote-Port
> > > > Co-simulation protocol for interfacing with SystemC modules. The first
> > > > revision was here:
> > > > https://lists.nongnu.org/archive/html/qemu-devel/2026-02/msg01760.html.
> > > >
> > > > As part of this submission, we would like to publish a sample project
> > > > serving as a demonstration of how to connect a QEMU Remote-Port
> > > > frontend to a SystemC backend.
> > > >
> > > > The sample project implements a standard SystemC IP core and uses
> > > > several external components such as:
> > > > - libsystemctlm-soc: https://github.com/Xilinx/libsystemctlm-soc
> > > > - VCML Library: https://github.com/machineware-gmbh/vcml
> > > > - SystemC Library: https://github.com/accellera-official/systemc
> > > >
> > > > We have a question regarding the location for this kind of project.
> > > > Could you please suggest if there is a preferred location or some
> > > > standard practice for hosting such a sample project?
> > >
> > > Location within the QEMU source tree?
> >
> > Yes, it would be good to include this project within the QEMU source tree.
> > To build the project, the mentioned SystemC, libsystemctlm-soc and
> > VCML libraries and their specific dependencies need to be built and
> > installed separately.
> > Would this approach be acceptable?
> >
> > Alternatively, is there an auxiliary repository within the QEMU
> > infrastructure that is better suited for these types of sample
> > projects,
> > perhaps somewhere under https://gitlab.com/qemu-project?
> 
> Do you have any thoughts on the preferred location for this sample project?

Why not just publish it under its own standalone git repo ? 

With regards,
Daniel

Re: Question on preferred location for QEMU sample projects

[Peter Maydell]

On Thu, 30 Apr 2026 at 05:48, Markus Armbruster <armbru@redhat.com> wrote:
>
> Ruslan Ruslichenko <ruslichenko.r@gmail.com> writes:
>
> > On Mon, Apr 13, 2026 at 4:04 PM Ruslan Ruslichenko
> > <ruslichenko.r@gmail.com> wrote:
> >> Yes, it would be good to include this project within the QEMU source tree.
> >> To build the project, the mentioned SystemC, libsystemctlm-soc and
> >> VCML libraries and their specific dependencies need to be built and
> >> installed separately.
> >> Would this approach be acceptable?
>
> We have a few (small) examples under contrib/.  However, Peter (cc'ed)
> has been trying to clean out that directory.
>
> >>
> >> Alternatively, is there an auxiliary repository within the QEMU
> >> infrastructure that is better suited for these types of sample
> >> projects,
> >> perhaps somewhere under https://gitlab.com/qemu-project?
> >>
> >> --
> >> BR,
> >> Ruslan
> >
> > Hello Markus,
> >
> > Do you have any thoughts on the preferred location for this sample project?


> Peter, what about you?

My general feeling is that we should not have sample projects
in the QEMU repo, because I think they tend to degenerate into
"this is old, unmaintained, and probably breaks without anybody
noticing it". We have enough trouble with the code that is
part of QEMU proper. This is why I am hoping we can clean
up "contrib/" -- I don't want unmaintained code that nobody
takes ownership of, and having a "contrib/" directory is like
a big sign saying "dump your garbage here and run away".

If we do have sample projects, we would need to have a
general approach to them which involved, for instance:
 * integrating them into our documentation, so that the
   docs for the associated QEMU feature could refer to them
 * shipping them in 'make install' as part of the docs
 * some kind of automated testing that they still work
   (by analogy with the way e.g. rust documentation code
   snippets can be tested)

That's a lot of work.

thanks
-- PMM