Re: [Qemu-discuss] sharing files between host and guest
If your disk image is RAW, try to attach it with ploop before partitioning, formatting or mounting volumes from it. After these preparations on the image, release any attachment or mount from the file before running Qemu using the image file. Using Qemu filesharing features, I only use SMB to 10.0.2.4 If you attach VM (tap0) to a host's bridge, you may prefer to treat it as a real machine in same host's network. * ICMP packets don't work between guest and others. Ping is not a good test for you. El 02/11/16 a les 21:03, Brooke Wallace ha escrit: > Hi folks, > > I'm new to QEMU and was able to pull the latest stable version and build > it. I downloaded a simple test arm image that I found in one of the docs > - arm-test-0.2.tar.gz and was able to run that w/o any problems. > > I grabbed the appropriate corss compiler tool chain for the ARM device > supported by that image, wrote and compiled a simple program. Now I want > to load that program on the device, but I can't find a simple method of > shareing files between the host and guest. > > This seems to be a pretty basic requirement, but the instructions I've > found in the docs are not working for me. I've tried multiple options > and am stuck at this point. Here is a summary of what I tried: > > 1. qemu-img to create an raw image, and mount that to the host >- was able to mount an image formated w/mkfs.ext4 >- not able to mount one partitioned with fdisk, tried many different > offsets >- not able to format a file image partitioned with fdisk > 2. unable to mount anything to the arm-test image other than the -initrd > arm_root.img that was provided > - tried many combinations of -hda, -drive and -device, eg. > |-hda test.img,fmt=raw| > |-drive if=none,file=test.img,format=raw,id=hda -device > ide-hd,drive=hda,bus=ide,unit=0 > 3. Tried creating a bridge to enable networking using the qemu-ifup/down > scripts documented. >-I'm able to ping 10.0.2.2, but can't ping my host ip 192.168.1.151 >-also tried tftp (after setting put anonymous ftp server on the > host), eg.| > > sudo qemu-ifup tap0 > qemu-system-arm -kernel zImage.integrator -initrd arm_root.img -machine > integratorcp -net nic -net tap,ifname=tap0,script=no,downscript=no > sudo qemu-ifdown tap0 > > It seems that the arm-test image does not have support for an IDE bus. I > found and sd card device on > the device and can read/write to it, but am not able to mount a host > file image to it using the -sd option. > > I did not want to get into compiling my own kernel yet, and emulating an > x86 image does not seem to be as > interesting as working with an ARM image. > > I've followed the procedures I've found on many different wikis, but my > overall impression is that the documentation > is very sparse, much of it out dated, and certainly not maintained. It > assume advanced knowledge of many aspects > Linux administration that are not normally used such as > paritioning/formating disks and setting up bridge networks. > > I also see several methods using a Windows host or mounting CIFS file > system - since I'm working on a Linux host > these are not attractive options. > > Its my goal to eventually get into the source code, but if just getting > started as a user is this difficult I may have to > reevaluate that goal. > > Any help would be greatly appreciated - this seems like something very > basic that should be well documented... > > -Brooke > > ||
Re: [Qemu-discuss] sharing files between host and guest
On 2 November 2016 at 20:03, Brooke Wallace wrote: > I'm new to QEMU and was able to pull the latest stable version and build it. > I downloaded a simple test arm image that I found in one of the docs - > arm-test-0.2.tar.gz and was able to run that w/o any problems. Firstly, sorry that this has been a bit of a painful first experience. You're right that the documentation online is generally not very good and I'd like us to do better there. One problem for ARM in particular is that QEMU has models of a lot of different machines, which are generally very different. So picking the right one can be confusing, especially if you're used to x86 where every machine looks like a PC. ARM guest kernels often won't work except on the machine they were built for. For instance, the "integratorcp" machine you've been trying to use is a very old development board (about 15 years old) and it doesn't have PCI, IDE or very much memory. I wouldn't recommend it unless you have a specific guest image which you absolutely need to run on that particular board. About the only machine model I can really solidly recommend is "virt" -- this is the board used for running KVM virtual machines; it doesn't correspond to any particular bit of real hardware but it has the best support for PCI, lots of memory, etc. The only slightly awkward part is that it doesn't have graphics out of the box (you might be able to plug in an emulated PCI graphics card but really it expects to be used via serial console). If you want 64-bit ARM then "virt" is pretty much the only sensible choice. I'd also recommend it for 32-bit. All the other boards I would suggest using only if you have a specific positive reason to want to use that board rather than "virt". (I'll have a look to see if there's a good tutorial for using the 'virt' board; we don't have any documentation for it officially on the QEMU wiki, because mostly we just provide the models of the hardware and leave it to other people to provide the guest software.) Some other suggestions: For networking for simple development purposes, the default "user mode" networking is fine, and there's no need to try to set up bridge networking. Bridge mode networking is really intended for serious x86-based virtual machines where networking performance is important, and I think most users there don't try to configure it by hand but use a management layer like libvirt to do the job. I've never bothered with setting up bridge mode in the 6 years I've been working on QEMU. If you don't give QEMU any networking arguments you should get the 'user mode' networking. The only important points to note are: (1) 'ping' doesn't work, so don't try to use it as a test (2) you can't directly connect from outside the VM to inside it unless you set up a specific port redirection on the QEMU command line. Connecting from inside the VM to outside works fine, though. For copying things into the VM I have two approaches: (1) easiest is just to use 'scp' or similar inside the VM to copy the file over the virtual network from the host machine (2) if there's a really huge amount of data, you can shutdown the VM, and then loopback mount its filesystem on the host PC to copy stuff in. Then unmount it from the host before restarting the VM. Other methods are also possible, but I've never needed to investigate them. The good news is that although this is an awkward "speed bump" in learning to work with QEMU, you only have to get over it once -- if you have a working setup it tends to stay working. This is part of why the documentation isn't great, I think most developers have some test images that they got working years ago so they don't need to re-establish them from scratch. thanks -- PMM
Re: [Qemu-discuss] sharing files between host and guest
Thanks for the sympathy Peter. Unfortunately the lack of documentation and reasonable introductory guide is making this a non-starter for us. 1. The integratorcp test image does not have scp the only command I can find for file transfer is tftp, but it looks like no one uses this anymore I also don't see another way to confirm network connectivity given that ping is expected to not work. 2. I still don't understand why I can't map the disk image "arm_root.img" to my host. I assume it has something to do with the fact that its passed to qemu as an -initrd image and not a -hda image? fdisk does not show any partitions or offset for this image to use in the mount command, but mount complains: $ 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 In some cases useful info is found in syslog - try dmesg | tail or so. There is nothing in dmesg or journalctl I'll can give "vrit" 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. Lack of good initial user documentation and a set of working examples will be a setback. One must be comfortable with and understand how the software is supposed to work before considering modification and reverse engineering is way too time consuming. 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. 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. From: Peter Maydell [peter.mayd...@linaro.org] Sent: Thursday, November 03, 2016 4:25 AM To: Brooke Wallace Cc: qemu-discuss@nongnu.org Subject: Re: [Qemu-discuss] sharing files between host and guest On 2 November 2016 at 20:03, Brooke Wallace wrote: > I'm new to QEMU and was able to pull the latest stable version and build it. > I downloaded a simple test arm image that I found in one of the docs - > arm-test-0.2.tar.gz and was able to run that w/o any problems. Firstly, sorry that this has been a bit of a painful first experience. You're right that the documentation online is generally not very good and I'd like us to do better there. One problem for ARM in particular is that QEMU has models of a lot of different machines, which are generally very different. So picking the right one can be confusing, especially if you're used to x86 where every machine looks like a PC. ARM guest kernels often won't work except on the machine they were built for. For instance, the "integratorcp" machine you've been trying to use is a very old development board (about 15 years old) and it doesn't have PCI, IDE or very much memory. I wouldn't recommend it unless you have a specific guest image which you absolutely need to run on that particular board. About the only machine model I can really solidly recommend is "virt" -- this is the board used for running KVM virtual machines; it doesn't correspond to any particular bit of real hardware but it has the best support for PCI, lots of memory, etc. The only slightly awkward part is that it doesn't have graphics out of the box (you might be able to plug in an emulated PCI graphics card but really it expects to be used via serial console). If you want 64-bit ARM then "virt" is pretty much the only sensible choice. I'd also recommend it for 32-bit. All the other boards I would suggest using only if you have a specific positive reason to want to use that board rather than "virt". (I'll have a look to see if there's a good tutorial for using the 'virt' board; we don't have any documentation for it officially on the QEMU wiki, because mostly we just provide the models of the hardware and leave it to other people to provide the guest software.) Some other suggestions: For networking for simple development purposes, the default "user mode" networking is fine, and there's no need to try to set up bridge networking. Bridge mode networking is really intended for serious x86-based virtual machines where networking performance is important, and I think most users there don't try to configure it by hand but use a management layer like libvirt to do the job. I've never bothered with setting up bridge mode in the 6 years I've been working on QEMU. If you don't give QEMU any networking arguments you should get the 'user mode' networking. The only important points to note are: (1) 'ping' doesn't work, so don't try to use it as a test (2) you can't directly connect from outside the VM
Re: [Qemu-discuss] sharing files between host and guest
On 3 November 2016 at 18:56, Brooke Wallace 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
Re: [Qemu-discuss] sharing files between host and guest
For network conectivity testing, you can try with "nc" to another TCP/UDP port. El 03/11/16 a les 19:56, Brooke Wallace ha escrit: > Thanks for the sympathy Peter. Unfortunately the lack of documentation and > reasonable introductory guide is making this a non-starter for us. > > 1. The integratorcp test image does not have scp >the only command I can find for file transfer is tftp, but it looks like > no one uses this anymore >I also don't see another way to confirm network connectivity given that > ping is expected to not work. > > 2. I still don't understand why I can't map the disk image "arm_root.img" to > my host. > I assume it has something to do with the fact that its passed to qemu as an > -initrd image and not a -hda image? > fdisk does not show any partitions or offset for this image to use in the > mount command, but mount complains: > > $ 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 > >In some cases useful info is found in syslog - try >dmesg | tail or so. > > There is nothing in dmesg or journalctl > > I'll can give "vrit" 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. > > Lack of good initial user documentation and a set of working examples will be > a setback. One must be comfortable with and understand how the software is > supposed to work before considering modification and reverse engineering is > way too time consuming. > > 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. > > 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. > > > From: Peter Maydell [peter.mayd...@linaro.org] > Sent: Thursday, November 03, 2016 4:25 AM > To: Brooke Wallace > Cc: qemu-discuss@nongnu.org > Subject: Re: [Qemu-discuss] sharing files between host and guest > > On 2 November 2016 at 20:03, Brooke Wallace wrote: >> I'm new to QEMU and was able to pull the latest stable version and build it. >> I downloaded a simple test arm image that I found in one of the docs - >> arm-test-0.2.tar.gz and was able to run that w/o any problems. > > Firstly, sorry that this has been a bit of a painful first > experience. You're right that the documentation online is > generally not very good and I'd like us to do better there. > > One problem for ARM in particular is that QEMU has models of > a lot of different machines, which are generally very different. > So picking the right one can be confusing, especially if you're > used to x86 where every machine looks like a PC. ARM guest kernels > often won't work except on the machine they were built for. > For instance, the "integratorcp" machine you've been trying to > use is a very old development board (about 15 years old) and > it doesn't have PCI, IDE or very much memory. I wouldn't > recommend it unless you have a specific guest image which > you absolutely need to run on that particular board. > > About the only machine model I can really solidly recommend is > "virt" -- this is the board used for running KVM virtual machines; > it doesn't correspond to any particular bit of real hardware > but it has the best support for PCI, lots of memory, etc. > The only slightly awkward part is that it doesn't have > graphics out of the box (you might be able to plug in an > emulated PCI graphics card but really it expects to be used > via serial console). If you want 64-bit ARM then "virt" is > pretty much the only sensible choice. I'd also recommend it > for 32-bit. > > All the other boards I would suggest using only if you have > a specific positive reason to want to use that board rather > than "virt". > > (I'll have a look to see if there's a good tutorial for > using the 'virt' board; we don't have any documentation for > it officially on the QEMU wiki, because mostly we just > provide the models of the hardware and leave it to other > people to provide the guest software.) > > Some other suggestions: > > For networking for simple development purposes, > the default "user mode" networking is fine, and > there's no need to try to set up bridge networking. > Bridge mode networking is really intended for serious > x86-based virtual machines where networking performance > is important, and I think most users there don't try to > configure it by hand but use a management layer like libvirt > to do the job.
Re: [Qemu-discuss] sharing files between host and guest
On 3 November 2016 at 19:42, Peter Maydell wrote: > On 3 November 2016 at 18:56, Brooke Wallace 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. Now public: https://translatedcode.wordpress.com/2016/11/03/installing-debian-on-qemus-32-bit-arm-virt-board/ If that seems to be useful I'll have a go at updating the QEMU wiki to point people at it later. thanks -- PMM
Re: [Qemu-discuss] sharing files between host and guest
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 [peter.mayd...@linaro.org] Sent: Thursday, November 03, 2016 12:42 PM To: Brooke Wallace Cc: qemu-discuss@nongnu.org Subject: Re: [Qemu-discuss] sharing files between host and guest On 3 November 2016 at 18:56, Brooke Wallace 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
Re: [Qemu-discuss] sharing files between host and guest
On 3 November 2016 at 22:48, Brooke Wallace 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
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 [peter.mayd...@linaro.org] Sent: Thursday, November 03, 2016 4:03 PM To: Brooke Wallace Cc: qemu-discuss@nongnu.org Subject: Re: [Qemu-discuss] sharing files between host and guest On 3 November 2016 at 22:48, Brooke Wallace 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
Re: [Qemu-discuss] sharing files between host and guest
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: qemu-discuss@nongnu.org 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 [peter.mayd...@linaro.org] Sent: Thursday, November 03, 2016 4:03 PM To: Brooke Wallace Cc: qemu-discuss@nongnu.org Subject: Re: [Qemu-discuss] sharing files between host and guest On 3 November 2016 at 22:48, Brooke Wallace 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
Re: [Qemu-discuss] sharing files between host and guest
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: qemu-discuss@nongnu.org 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 [peter.mayd...@linaro.org] Sent: Thursday, November 03, 2016 4:03 PM To: Brooke Wallace Cc: qemu-discuss@nongnu.org Subject: Re: [Qemu-discuss] sharing files between host and guest On 3 November 2016 at 22:48, Brooke Wallace 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
[Qemu-discuss] Where are local APIC addresses in QEMU?
Hi list, I'm doing some LAPIC programing. According to Intel's document, FEE0 H to FEE0 03F0H is the range of local APIC. However, examining it from QEMU console, I can only find the value 0 there: (qemu) x/128b 0xfee0 fee0: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00010: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00018: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00020: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00028: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00030: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00038: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00040: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00048: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00050: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00058: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00060: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00068: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00070: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 fee00078: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 I checked 128 bytes to see if anything different than 0. At least, FEE0 0030H should contain a different value since it is where APIC version is in. Only protected mode is enabled; paging is disabled, so there's no virtual memory: (qemu) info mem PG disabled But, `info lapic` command reports actual initial values: (qemu) info lapic dumping local APIC state for CPU 0 LVT0 0x8700 active-hi level ExtINT (vec 0) LVT1 0x8400 active-hi level NMI LVTPC0x0001 active-hi edge masked Fixed (vec 0) LVTERR 0x0001 active-hi edge masked Fixed (vec 0) LVTTHMR 0x0001 active-hi edge masked Fixed (vec 0) LVTT 0x0001 active-hi edge masked one-shot Fixed (vec 0) TimerDCR=0x0 (divide by 2) initial_count = 0 SPIV 0x01ff APIC enabled, focus=off, spurious vec 255 ICR 0x000c4610 physical edge assert all ICR2 0x ESR 0x ISR (none) IRR (none) APR 0x00 TPR 0x00 DFR 0x0f LDR 0x00 PPR 0x00 So, where are these values? Thanks.
