Virtual devices for QEMU and Bochs

KOLANICH commented 4 years ago

Project description

Android phones use chips that often lack free open-source drivers. To develop these drivers it is needed to be able to load the drivers into a virtual computer and allow them to interact with something that behaves like hardware.

It would be much more convenient if it would be possible to

develop a model of a device from its datasheet using a combination of SystemC/SystemVerilog/VHDL/other langs (ie. it may be possible to plug there a python interpreter somehow) code and a file with metadata; it should be allowed to use the code in other langs from within of SystemVerilog/VHDL/SystemC code too, for example by linking a static or a shared lib and using language extensions. The device model should be able to drive a virtual clock.
compile the model into a native shared library that can be loaded by a recompilator/emulator;
the emulator loads the module and creates necessary virtual hardware devices inside of itself based on the info from the manifest. Tracing and logging and debugging should also be available;
it should be possible to replace the device without rebooting the VM

Probably a unified interface is needed to support both bochs and qemu.

Relevant Technology

https://github.com/qemu/qemu https://github.com/jsjohnst/bochs https://github.com/accellera-official/systemc https://sourceforge.net/projects/verilog2cpp https://www.veripool.org/wiki/verilator

Complexity and required time

Complexity

[x] Advanced - The project requires the user to have a good understanding of all components of the project to contribute

Required time (ETA)

[x] Much work - The project will take more than a couple of weeks and serious planning is required

Categories

[x] Developer Tooling

remram44 commented 4 years ago

Isn't it easier to write the driver than the virtual device?

Manishfoodtechs commented 4 years ago

Why only QEMU ? what about LXC hypervisor ?

I m not sure about LXC on Android. But, I believe LXC should work on Android as later OS having Linux in behind,

why I am inclining more for LXC hypervisor over QEMU or KVM because of difference in resource usage.

please check out difference between kvm / QEMU and LXC.

https://dev.to/manishfoodtechs/creating-your-cloud-infrastructure-like-google-cloud-and-digital-ocean-from-scratch-part-2-5f7f

On Sat, Dec 21, 2019, 22:29 Remi Rampin notifications@github.com wrote:

Isn't it easier to write the driver than the virtual device?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/open-source-ideas/open-source-ideas/issues/216?email_source=notifications&email_token=AHACKLOYPG44P7YBTRHLGULQZZDPPA5CNFSM4J6H2CBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHO7VQA#issuecomment-568195776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHACKLOFAUR7RFZH3PSHHKTQZZDPPANCNFSM4J6H2CBA .

KOLANICH commented 4 years ago

Isn't it easier to write the driver than the virtual device?

I guess no. Most of complexity of real devices is in devices themselves. We don't need to implement the virtual devices themselves accurately matching real ones, we only need their interface documented in datasheets. Or undocumdnted interfaces, in this case we have to reverse-engineer them first. Models can be written in a high-level language (even python). Also writing them can be done only once. Once you have a device model, it can work with any OS when that OS needs drivers to be developed.

But drivers are a bit different. They run in kernel space, so one can break an OS easily (it's better to write them in rust since it has at least some guarantees of memory safety, but even though it is easy to break the OS using its api for drivers) to the state requiring reboot. And they are written in low-level languages.

Anyway, in order to develop anything one needs a loop "make change-observe the result-if needed, tap inside" be fast. So either in-circuit emulation when the cpu is in PC and peripherials are real, or virtualize everything, or use the real device. But everything except virtualization requires a devboard. It may be inacceptible. Vendors' developers have devboards for all the hardware they develop drivers for. Hobbists don't.

KOLANICH commented 4 years ago

what about LXC hypervisor ?

LXC is not a hypervisor.
One cannot use LXC to emulate hardware.

Manishfoodtechs commented 4 years ago

I don't know will this be any use for your project. Give a look on https://halium.org/ . Kindly take Halium Project as only a share from my side.

On Sat, Dec 21, 2019, 23:06 KOLANICH notifications@github.com wrote:

what about LXC hypervisor ?

LXC is not a hypervisor.

One cannot use LXC to emulate hardware.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/open-source-ideas/open-source-ideas/issues/216?email_source=notifications&email_token=AHACKLKQIVYFEUM45GKHGLLQZZHZ7A5CNFSM4J6H2CBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHPAJYQ#issuecomment-568198370, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHACKLL6XVVMEUORDR7KGALQZZHZ7ANCNFSM4J6H2CBA .

KOLANICH commented 4 years ago

Thanks for the info.

open-source-ideas / ideas