qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jakob Bohm
Subject: Re: [Qemu-discuss] sharing files between host and guest
Date: Fri, 4 Nov 2016 05:28:26 +0100
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Some versions of the gcc startup code initializes floating point
processor/feature even if the program doesn't use it.

Historically, this created a problem because the Linux kernel (on 32
bit x86) could context switch faster if it knew a process never touched
the floating point state, but gcc ruined that by making every process
touch that.

On 04/11/2016 00:59, Brooke Wallace wrote:
Well, ok playing with the cpio options seems to have done the trick:

zcat ../arm_test.img | cpio -idmv
find . | cpio -ov -R root --format=newc | gzip > ../test.img

I can boot the new image now, and run my test app - of course it didn't work, its giving 
me "Floating point exception", lol.

Pretty sure I have the correct cross compile tool chain, and its a simple main 
program to just return a value - no libs required - well thats not entirely 
true - it has all that std c/gnu garbage.

Still, I did not expect a floating point exception...
________________________________________
From: Brooke Wallace
Sent: Thursday, November 03, 2016 4:33 PM
To: Peter Maydell
Cc: address@hidden
Subject: RE: [Qemu-discuss] sharing files between host and guest

Well, I was able to unpack the arm_test.img and add my file, but after 
repacking and using as a boot image I get a Kernel panic - not syncing: VFS: 
Unable to mount root fs unknown-block(0,0)

Pretty sure there must be some different options in use than whats given at the 
link https://access.redhat.com/solutions/24029


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

On 3 November 2016 at 22:48, Brooke Wallace <address@hidden> wrote:
Thanks again Peter,

Is there anyway to mount an -initrd image to the host?
You can't directly mount it, because it's not a filesystem.
But there are tools for manipulating initrd images:
something like https://access.redhat.com/solutions/24029
should work at a very low level, and there's probably
some higher-level tools as well. The same things that
work for manipulating an initrd for your host system
should work just as well on one for the guest.

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.
A full OS is much easier to work with, because you
don't have to keep recreating an embedded filesystem
image every time you do anything, and you don't need
to go through the pain of assembling and cross
compiling lots of library dependencies for every
program you want to use inside the VM.
 From QEMU's point of view there's no difference,
it's just running a kernel and some userspace programs,
so you might as well pick the userspace that's easy
to work with. (If you want an embedded fs image
you could have a look at https://buildroot.org, but
it's likely to be more work to get that running than
just to use Debian.)

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.
We deliberately don't have a plugin architecture.
New board and device models should be implemented
in QEMU's source tree and (ideally) upstreamed.
The "how to add a new board or devices" is unfortunately
still at the level of "look at one that was added
recently and see how it was done".

thanks
-- PMM




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded




reply via email to

[Prev in Thread] Current Thread [Next in Thread]