qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* QEMU Library support
@ 2020-08-10  5:06 Pratik Parvati
  2020-08-10  9:48 ` Alex Bennée
  0 siblings, 1 reply; 6+ messages in thread
From: Pratik Parvati @ 2020-08-10  5:06 UTC (permalink / raw)
  To: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

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.

Regards,
Pratik

[-- Attachment #2: Type: text/html, Size: 565 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: QEMU Library support
  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-20  5:18   ` Pratik Parvati
  0 siblings, 2 replies; 6+ messages in thread
From: Alex Bennée @ 2020-08-10  9:48 UTC (permalink / raw)
  To: Pratik Parvati; +Cc: qemu-devel


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: QEMU Library support
  2020-08-10  9:48 ` Alex Bennée
@ 2020-08-10  9:59   ` Pratik Parvati
  2020-08-10 10:20     ` Alex Bennée
  2020-08-20  5:18   ` Pratik Parvati
  1 sibling, 1 reply; 6+ messages in thread
From: Pratik Parvati @ 2020-08-10  9:59 UTC (permalink / raw)
  To: Alex Bennée; +Cc: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 1669 bytes --]

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?

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
>

[-- Attachment #2: Type: text/html, Size: 2236 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: QEMU Library support
  2020-08-10  9:59   ` Pratik Parvati
@ 2020-08-10 10:20     ` Alex Bennée
  2020-08-10 13:31       ` Pratik Parvati
  0 siblings, 1 reply; 6+ messages in thread
From: Alex Bennée @ 2020-08-10 10:20 UTC (permalink / raw)
  To: Pratik Parvati; +Cc: qemu-devel


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: QEMU Library support
  2020-08-10 10:20     ` Alex Bennée
@ 2020-08-10 13:31       ` Pratik Parvati
  0 siblings, 0 replies; 6+ messages in thread
From: Pratik Parvati @ 2020-08-10 13:31 UTC (permalink / raw)
  To: Alex Bennée; +Cc: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

Just to hide the core QEMU implementation from the device code. QEMU core
source code remains the same for all device; So, was thinking a way of
hiding it from the rest of the device code.

Regards,
Pratik


On Mon, Aug 10, 2020 at 3:50 PM Alex Bennée <alex.bennee@linaro.org> wrote:

>
> 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
>

[-- Attachment #2: Type: text/html, Size: 3319 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: QEMU Library support
  2020-08-10  9:48 ` Alex Bennée
  2020-08-10  9:59   ` Pratik Parvati
@ 2020-08-20  5:18   ` Pratik Parvati
  1 sibling, 0 replies; 6+ messages in thread
From: Pratik Parvati @ 2020-08-20  5:18 UTC (permalink / raw)
  To: Alex Bennée; +Cc: qemu-devel

[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]

>> 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, to answer your earlier question, this is only for experimental
purposes -
to learn Qemu device modeling API better. I am trying to understand QEMU
build hierarchy and proceed to see whether I can find any solution out of
it.

Also - wanted to set right one point. The Greensocs SystemC bridge is
definitely an option if one wants to integrate device models in SystemC -
but in my case, I wanted to better understand Qemu internals.

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
>

[-- Attachment #2: Type: text/html, Size: 3461 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-08-20  5:19 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2020-08-10 13:31       ` Pratik Parvati
2020-08-20  5:18   ` Pratik Parvati

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).