[Qemu-devel] Minimal Qemu build for Plan9

[Qemu-devel] Minimal Qemu build for Plan9

[Ashish Kaila]

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

Hi,

 

I am a graduate student from CMU and currently working on trying to port
Qemu on plan9. I was trying to initially build a minimal Qemu with the least
set of devices that are necessary to support a machine, however I noticed
that I couldn't understand some of the dependencies such as requiring an
audio driver during initialization. I am currently trying to port just the
i386-softmmu version of Qemu to plan9 to keep things simple, here I noticed
that  pc_init1() initializes a host of devices on the PCI bus like the NIC
card etc and was wondering if there is a bare minimum set of devices that
Qemu needs to be built with ?

 

Additionally if someone could point me to a to-do list of things to look out
for while porting Qemu on a new platform (new OS/hardware), I would be
extremely grateful.

 

Thanks & Regards

Ashish


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

Re: [Qemu-devel] Minimal Qemu build for Plan9

[Andreas Färber]

Hi,

Am 30.09.2013 10:00, schrieb Ashish Kaila:
> I am a graduate student from CMU and currently working on trying to port
> Qemu on plan9. I was trying to initially build a minimal Qemu with the
> least set of devices that are necessary to support a machine, however I
> noticed that I couldn’t understand some of the dependencies such as
> requiring an audio driver during initialization. I am currently trying
> to port just the i386-softmmu version of Qemu to plan9 to keep things
> simple, here I noticed that  pc_init1() initializes a host of devices on
> the PCI bus like the NIC card etc and was wondering if there is a bare
> minimum set of devices that Qemu needs to be built with ?

Configuring with --target-list=i386-softmmu should already give you a
minimal set of devices, omitting those that are irrelevant for x86 but
including a few optional ones.

However I don't understand why devices emulated in C code would pose a
porting problem for you? If the code is not using portable POSIX
constructs or suitable #ifdefs then please post patches to fix that
rather than working around those type of things.

> Additionally if someone could point me to a to-do list of things to look
> out for while porting Qemu on a new platform (new OS/hardware), I would
> be extremely grateful.

osdep.c and related files come to mind, configure obviously.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] Minimal Qemu build for Plan9

[Peter Maydell]

On 30 September 2013 17:00, Ashish Kaila <ashishkaila9@gmail.com> wrote:
> Additionally if someone could point me to a to-do list of things to look out
> for while porting Qemu on a new platform (new OS/hardware), I would be
> extremely grateful.

It doesn't get ported to new OSes very often, so there's no todo list
already written. Do make sure you're using either a reasonably recent
(4.x) gcc or clang: we make use of various compiler extensions that
I don't think any other C compiler provides.

Looking at the code I don't think we require an audio driver: if
there is no available audio backend for the platform we should
fall back to the two work-anywhere backends ("discard all audio"
and "send audio to a .wav file").

-- PMM

Re: [Qemu-devel] Minimal Qemu build for Plan9

[Stefan Hajnoczi]

On Mon, Sep 30, 2013 at 04:00:05AM -0400, Ashish Kaila wrote:
> Additionally if someone could point me to a to-do list of things to look out
> for while porting Qemu on a new platform (new OS/hardware), I would be
> extremely grateful.

Has glib been ported to Plan 9?  You need it since much of QEMU uses
this library.

I guess the code you'll need to port are timers, thread pools, signal
handling, thread-local storage and pthread usage, and maybe some
mmap/mprotect calls.

QEMU uses a coroutines implementation which is done using
makecontext()/sigsetjmp()/siglongjmp() on Linux.  Other OSes have their
own coroutine implementations (see coroutine-*.c).

This port is a lot of work.  If you want to upstream the patches,
consider if you're willing to test and maintain Plan 9 support in the
long term.  Since QEMU is actively developed just getting a port merged
isn't enough, you need to stay involved and continue maintaining it
otherwise the port would bitrot/need to be dropped.

Stefan