>> 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.ben...@linaro.org> wrote: > > Pratik Parvati <prat...@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 >
