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

[Peter Maydell]

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