Re: [Qemu-discuss] sharing files between host and guest

[Brooke Wallace]

Thanks again Peter,

Is there anyway to mount an -initrd image to the host? Can I unzip it or 
something? I'd just like to run my cross-compiled app and say that it worked. 
Then maybe I can start poking around in the code and see where I can start 
adding some hooks.

Send me a pointer to the blog when your done pls. I appreciate the help.

I'm not interested in booting Windows, and don't require a full blown Debian OS 
- in fact I would expect a busybox image for an embedded device. 

Thanks for the heads up on the Android emulation - I'd rather not deal with all 
the Java clutter anyway.

Ultimately I would be more interested in a Bagel Bone Black or Pi2 device 
emulation, but I've got to start somewhere.

I would be happy with a current ARM core, running a linux kernel and some basic 
libs like libc, and of course, some way to share files between the host and 
guest system. Then maybe an API or some docs providing a description of how one 
is expected to modify the code (well implementing plugins would be best) to 
emulate their particular hardware.



________________________________________
From: Peter Maydell address@hidden
Sent: Thursday, November 03, 2016 12:42 PM
To: Brooke Wallace
Cc: address@hidden
Subject: Re: [Qemu-discuss] sharing files between host and guest

On 3 November 2016 at 18:56, Brooke Wallace <address@hidden> wrote:
> Thanks for the sympathy Peter. Unfortunately the lack of documentation
> and reasonable introductory guide is making this a non-starter for us.

Yeah, I was surprised there wasn't a decent guide to getting
the 'virt' board working; I've spent this afternoon writing up
a blog post describing how to get Debian working on it, which
I'll finish off and publish this evening.

> 2. I still don't understand why I can't map the disk image
> "arm_root.img" to my host.

> $ sudo mount -t auto -o loop arm_root.img /mnt/qemu
> mount: wrong fs type, bad option, bad superblock on /dev/loop1,
>        missing codepage or helper program, or other error

initrd images aren't the same thing as disk images (they're
usually gzipped, and may be cpio archives rather than actual
filesystems). I would really forget about this ancient
image, it is just leading you down the wrong path.

> I'll can give "virt" a try, but I'm looking for a working
> example that can be mapped to real hardware, eg. RaspberryPI,
> Beagle Bone Black or something similar. Working in a emulation
> for a virtual machine does me no good. Our goal is to emulate
> actual hardware and ultimately understand how to modify QEMU
> to add hooks and add emulations for new hardware.

We have a raspi2 model, but it is a bit half-finished,
so it won't actually boot current Raspbian. (It is supposedly
able to boot Windows...) You can play with that if you like
but you'll be spending a lot of time figuring out how to fix
bugs in the device emulation. On the other hand, if you are
interested in learning about how device models work then
fixing bugs in an existing model might be a good way to start.
Let me know if you'd like to try going down this path and
I'll look up the current state of this (ie command lines
and images that work up until the point where the kernel
falls over because it wants to talk to a device that isn't
in our model).

Note that although "virt" is not a piece of real hardware,
the principles of what an emulated machine looks like are
still very similar, and it does include numerous components
that are exactly models of real hardware (like the interrupt
controller, serial ports, GPIO controller...) The only
difference from our models of 'real hardware' is that:
 * it is free to include devices that are useful even if
   there isn't an SoC in the world that happens to have
   them (like the PCI controller)
 * it doesn't need to bother to model silly details of
   real hardware (like only having 256MB of RAM or having
   PS/2 keyboard and mouse ports, or whatever)
So it sounds to me like it might be pretty much as good for
your purposes as the 'raspi2' model would be.

> I can see that lack of any API for adding emulations, or
> documentation of an API is also going to be an issue for
> us here as well when considering whether or not to invest
> our time in this effort.

We don't have public-facing device documentation, no.
We've been trying to enforce having documentation comments
in the header files for new APIs, but old ones still have
no documentation and there's a bit of a lack of overview-level
guides. This is all something we'd like to do better with.

> I know that QEMU is part of the Android emulation, and I
> wonder if going that route may be more productive -
> although were really not interested in android.

I think you will find it no different in the areas that
you are having difficulty with. (The android emulator
is also a "virtual" platform that's not real hardware,
for instance, and the codebase is pretty much the same
except with a lot of extra code for Android-emulator
specific handling of OpenGL and so on.)

thanks
-- PMM