From: "Alex Bennée" <alex.bennee@linaro.org>
To: Pratik Parvati <pratikp@vayavyalabs.com>
Cc: qemu-devel@nongnu.org
Subject: Re: QEMU Library support
Date: Mon, 10 Aug 2020 11:20:49 +0100 [thread overview]
Message-ID: <87lfim3ipq.fsf@linaro.org> (raw)
In-Reply-To: <CA+aXn+ETrBneXK3N6+gzO_7R=6mdxXr_Oig7MjOe7VzO5OD0mg@mail.gmail.com>
Pratik Parvati <pratikp@vayavyalabs.com> writes:
> As an experiment, I have modelled non-existing ARM Watchdog model (SP805)
> interfaced to the versatile PB platform. What actually I was looking is -
> some sort of QEMU library, where I can model new device outside the QEMU
> source hierarchy and still be able to compile it using QEMU library and
> include files to add support for the new device. If QEMU doesn't provide a
> library, Is there a flexibly that I can tweak something inside the QEMU to
> generate it?
Not really. While most devices are fairly standalone they can access all
sorts of QEMU APIs. Why not just implement your device inside the QEMU
source tree?
>
> Regards,
> Pratik
>
>
> On Mon, Aug 10, 2020 at 3:18 PM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>>
>> Pratik Parvati <pratikp@vayavyalabs.com> writes:
>>
>> > Hi team,
>> >
>> > Lately, I have been working on QEMU modeling and interfacing it into the
>> > existing platform. What actually I wanted to check is; whether QEMU
>> > supports library that gives developers a clean interface to develop and
>> > integrate peripheral model in to QEMU. I know of the Greensocs SystemC
>> > bridge - but that was quite difficult to work with in past.
>>
>> Not really - with a few exceptions like vhost-user and in KVM device
>> emulation all devices are emulated in the QEMU code base. As a result
>> the best way to maintain a device is to have it integrated upstream
>> (along with some tests to ensure it is working).
>>
>> As you note there are various forks of QEMU that support device
>> modelling but none of these features have been merged upstream and would
>> likely need to assuage worries about such interfaces being used to avoid
>> GPL compliance.
>>
>> What sort of devices are you looking to model? Are these existing
>> devices or experimental/research things?
>>
>> --
>> Alex Bennée
>>
--
Alex Bennée
next prev parent reply other threads:[~2020-08-10 10:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 5:06 QEMU Library support Pratik Parvati
2020-08-10 9:48 ` Alex Bennée
2020-08-10 9:59 ` Pratik Parvati
2020-08-10 10:20 ` Alex Bennée [this message]
2020-08-10 13:31 ` Pratik Parvati
2020-08-20 5:18 ` Pratik Parvati
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lfim3ipq.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=pratikp@vayavyalabs.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).