Re: [Qemu-discuss] Trouble starting various qemu-system-*.exe on Windows 7

[Steere, Andy]

Thanks for the clarifying. I now understand that not passing arguments would 
get different behavior so I will ask a simpler form of my question.

Running "qemu-system-mipsel --help" on Ubuntu 14.0 gives a help message.

Should Windows "qemu-system-mipsel --help" running as administrator give a help 
message?  

Thanks,
Andy

-----Original Message-----
From: address@hidden [mailto:address@hidden On Behalf Of address@hidden
Sent: Friday, June 13, 2014 2:50 AM
To: address@hidden
Subject: Qemu-discuss Digest, Vol 33, Issue 13

Send Qemu-discuss mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.nongnu.org/mailman/listinfo/qemu-discuss
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Qemu-discuss digest..."


Today's Topics:

   1. Re: How can we install RPMs in guest VM from host machine
      using QEMU guest agents (Mike Lovell)
   2. Re: How can we install RPMs in guest VM from host machine
      using QEMU guest agents (Dale R. Worley)
   3. Re: Trouble starting various qemu-system-*.exe on Windows 7
      (Peter Maydell)
   4. Re: qemu -kernel u-boot.bin (Peter Maydell)
   5. i386 qemu, coreboot and FILO (Martin Erts?s)
   6. qemu daemon mode, create snapshot error
      (=?ISO-8859-1?B?bGlhbmc=?=)
   7. Re: qemu -kernel u-boot.bin (Matwey V. Kornilov)


----------------------------------------------------------------------

Message: 1
Date: Thu, 12 Jun 2014 14:19:08 -0600
From: Mike Lovell <address@hidden>
To: address@hidden
Subject: Re: [Qemu-discuss] How can we install RPMs in guest VM from
        host machine using QEMU guest agents
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 06/12/2014 04:32 AM, Puneet wrote:
> Hi,
>
> I want to be able to install RPM packages (available in host system at 
> some
> path) to the guest VM and want this facility to be available as a tool.
>
> I am thinking of having a gemu guest agent (qemu-ga) running inside 
> guest VM. I did not find any available command ("virsh 
> qemu-agent-command <guest_vm> ...") which can do the same.
>
> I am planning to write a command in qemu guest agent, which I can 
> invoke from virsh like below.
>
>      "virsh qemu-agent-command vm_01          \
>          '{"execute":"guest-rpm-install",     \
>            "arguments":{"path":"/usr/local/bin/ABC.rpm"}}
>        
> I am able to pass arguments from host to guest VM but how am I 
> supposed to pass the whole RPM image from host to guest (which the 
> guest agent can receive and install)?

according to the schema for the guest agent commands [1], there are several 
commands for opening and writing a file in the guest. you could use those to 
transfer a file to the guest. it would be something like guest-file-open, one 
or more guest-file-write commands to transfer bits of data read from a file on 
the host, and then a guest-file-close. i don't know if libvirt would support 
this so you would probably have to implement a program to run on the host that 
communicates with the guest agent to transfer the file. there is a script in 
the qemu source tree that has the same basic idea for reading a file from the 
guest in python. [2] look at the QemuGuestAgentClient.read function. it could 
probably be easily modified to transfer a file to the guest.

the harder part is going to be executing rpm, yum, or any other command in the 
guest. the command schema doesn't currently list a command to execute an 
arbitrary executable in the guest so you would either need to implement a 
command to execute an arbitrary executable or specifically execute the rpm or 
yum commands you need. the later would be a little better from a security 
perspective. and of course rpm wont work on your windows vms though the same 
basic idea might apply.

mike

[1] http://git.qemu-project.org/?p=qemu.git;a=blob;f=qga/qapi-schema.json
[2]
http://git.qemu-project.org/?p=qemu.git;a=blob;f=scripts/qmp/qemu-ga-client



------------------------------

Message: 2
Date: Thu, 12 Jun 2014 17:52:59 -0400
From: address@hidden (Dale R. Worley)
To: Puneet Bakshi <address@hidden>
Cc: address@hidden
Subject: Re: [Qemu-discuss] How can we install RPMs in guest VM from
        host machine using QEMU guest agents
Message-ID: <address@hidden>

> From: Puneet Bakshi <address@hidden>
> 
> Forgot to mention that these guest VMs can be UNIX based or Windows.

How do you install an RPM on Windows?

Dale



------------------------------

Message: 3
Date: Thu, 12 Jun 2014 23:32:04 +0100
From: Peter Maydell <address@hidden>
To: "Steere, Andy" <address@hidden>
Cc: "address@hidden" <address@hidden>
Subject: Re: [Qemu-discuss] Trouble starting various qemu-system-*.exe
        on Windows 7
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=UTF-8

On 11 June 2014 00:50, Steere, Andy <address@hidden> wrote:
> Curious I wrote a simple script to start all the qemu-system-*.exe files in
> the distribution without any arguments. The results were mixed. Some of the
> qemu exes start a qemu window. Others write to the event log and the last
> group does not write anything to stdout or stderr.

This is to some extent expected. Not all board models
can work with no arguments at all specified. The i386
PC model happens to ship with a BIOS image which is
run by default, but not all hardware has a similar concept
(some of our models are of development boards where
you're expected to provide the equivalent of the ROM
image yourself).

Common errors that can result in no useful output:
 * forgot to provide a kernel to run
 * provided a kernel but it only outputs on serial and you
   didn't tell QEMU to send serial output anywhere useful
 * guest kernel is misconfigured and crashes before
   printing any output
 * guest kernel is for a completely different machine and
   has no chance of working

thanks
-- PMM



------------------------------

Message: 4
Date: Thu, 12 Jun 2014 23:43:50 +0100
From: Peter Maydell <address@hidden>
To: "Matwey V. Kornilov" <address@hidden>
Cc: "Dale R. Worley" <address@hidden>,  qemu-discuss
        <address@hidden>
Subject: Re: [Qemu-discuss] qemu -kernel u-boot.bin
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=UTF-8

On 10 June 2014 16:25, Matwey V. Kornilov <address@hidden> wrote:
> Only this instructions are executed:
>
>   >?0x60000000 <_start>                     mov    r0, #0
>                                                      ?
>    ?0x60000004 <_start+4>                   ldr    r1, [pc, #6397080]
>     ; 0x60000010 <_start+16>                         ?
>    ?0x60000008 <_start+8>                   ldr    r2, [pc, #6397080]
>     ; 0x60000014 <_start+20>                         ?
>    ?0x6000000c <_start+12>                  ldr    pc, [pc, #6397080]
>     ; 0x60000018 <_start+24>                         ?
>
> Next stepi brings me to 0x60010000

This is entirely expected.

>>> qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1024 -kernel u-boot.bin
>>> -serial stdio

You said that u-boot.bin was a Linux kernel (that's what "-kernel"
means for non-ELF files), so we load your binary in accordance
with the documented requirements for booting a Linux kernel:
 * load kernel at offset 0x10000 in RAM
 * run a little stub code fragment to set r0 to 0, r1 to the board
   ID, r2 to the address of device tree / kernel ATAGS list, and
   then jump to the kernel start at offset 0x10000 into RAM

What you're seeing here is that we execute those four instructions
which are the stub code loader and then jump to where your
"kernel" starts.

If you don't want to be started like a kernel, don't use -kernel :-)

You could either (a) use an ELF file and take advantage of the
fact we just load ELF files at the address they're linked at and
then start at the ELF entrypoint or (b) If you're really trying to be
a boot rom you probably want to provide a complete 64MB flash
image via the "-pflash flash.bin" command line argument
(then don't use -kernel at all, and we'll start at address 0, which
is the flash, just as the real hardware does).

thanks
-- PMM



------------------------------

Message: 5
Date: Fri, 13 Jun 2014 08:35:00 +0200
From: Martin Erts?s <address@hidden>
To: address@hidden
Subject: [Qemu-discuss] i386 qemu, coreboot and FILO
Message-ID: <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

Hi.

I have made a disk image running android, which I can start with

qemu-system-i386 \
    -name "Sunrise"
    -enable-kvm \
    -smp 1 \
    -m 256 \
    -kernel bzImage \
    -initrd initrd.cpio.gz \
    -append "root=/dev/vda console=ttyS0 vga=0x389
androidboot.hardware=sunrise" \
    -drive
"file=sunrise.disk,if=none,id=drive-virtio-disk0,format=raw,cache=none" \
    -device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
\
    -vga std \
    -serial stdio \
    -soundhw hda
    -device virtio-net-pci,netdev=br0,id=nic1 \
    -netdev tap,id=br0

This works fine, but the same sunrise.disk have a menu.lst located at
/active/menu.lst on partition one. So I made a coreboot bios using FILO,
and made FILO look under hda1:/active/menu.lst. The menu.lst looks like:

title Sunrise
root (hd0,0)
kernel /active/bzImage root=/dev/vda console=ttyS0 vga=0x389
androidboot.hardware=sunrise
initrd /active/initrd.cpio.gz
boot

And my qemu commandline have then changed to:

qemu-system-i386 \
    -name "Sunrise"
    -enable-kvm \
    -smp 1 \
    -m 256 \
    -bios bios.bin \
    -drive
"file=sunrise.disk,if=none,id=drive-virtio-disk0,format=raw,cache=none" \
    -device
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
\
    -vga std \
    -serial stdio \
    -soundhw hda
    -device virtio-net-pci,netdev=br0,id=nic1 \
    -netdev tap,id=br0

However, FILO complains that it can not find hda1:/active/menu.lst

If I remove the -device virtio-blk-pci line and remove if=none from the
drive line, I can boot it, but I experience other weird behaviour. I
would also like to not have to change this bootup line to much, as block
device is more similar to what we will actually have on a real target.
Have anyone experienced something similar and can help me out? I have to
hypoteses:

1) The name of the drive is not hda1 when FILO starts, it's not vda
either, so if that is the case, someone with more qemu experience would
have to help me out here
2) The bios part of coreboot struggles to find the drive

Thanks in advance

Kind Regards
Martin Erts?s



------------------------------

Message: 6
Date: Fri, 13 Jun 2014 16:13:05 +0800
From: "=?ISO-8859-1?B?bGlhbmc=?=" <address@hidden>
To: "=?ISO-8859-1?B?UWVtdS1kaXNjdXNz?=" <address@hidden>
Subject: [Qemu-discuss] qemu daemon mode, create snapshot error
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

hi all,


    I use -daemonize start my qemu-system-x86 (qemu-1.7.1), and when I use the 
monitor cmd "snapshot_blkdev" create snapshot, it return error: 
         Could not open 'windows7.qcow2': Could not open 'windows7.qcow2': No 
such file or directory: No such file or directory



   windows7.qcow2 is my ide-hd0.




thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.nongnu.org/archive/html/qemu-discuss/attachments/20140613/fcc43db7/attachment.html>

------------------------------

Message: 7
Date: Fri, 13 Jun 2014 12:50:01 +0400
From: "Matwey V. Kornilov" <address@hidden>
To: Peter Maydell <address@hidden>
Cc: "Dale R. Worley" <address@hidden>,  qemu-discuss
        <address@hidden>
Subject: Re: [Qemu-discuss] qemu -kernel u-boot.bin
Message-ID:
        <address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

2014-06-13 2:43 GMT+04:00 Peter Maydell <address@hidden>:
> You said that u-boot.bin was a Linux kernel (that's what "-kernel"
> means for non-ELF files), so we load your binary in accordance
> with the documented requirements for booting a Linux kernel:
>  * load kernel at offset 0x10000 in RAM
>  * run a little stub code fragment to set r0 to 0, r1 to the board
>    ID, r2 to the address of device tree / kernel ATAGS list, and
>    then jump to the kernel start at offset 0x10000 into RAM

Thanks, I've started to realize that. Initially, I googled lots of
howto-s saying that I have to pass u-boot through -kernel.

> What you're seeing here is that we execute those four instructions
> which are the stub code loader and then jump to where your
> "kernel" starts.
>
> If you don't want to be started like a kernel, don't use -kernel :-)
>
> You could either (a) use an ELF file and take advantage of the
> fact we just load ELF files at the address they're linked at and
> then start at the ELF entrypoint or

Yes, this works, see my mail above.

(b) If you're really trying to be
> a boot rom you probably want to provide a complete 64MB flash
> image via the "-pflash flash.bin" command line argument
> (then don't use -kernel at all, and we'll start at address 0, which
> is the flash, just as the real hardware does).

What I am really want to do is to make u-boot to load the
kernel/initrd/dtb from the partition on sd image attached.

I am stuck here. I've put u-boot binary on the 0 of flash.bin (which
is 67108864 bytes long), and run following

qemu-system-arm -M vexpress-a9 -pflash pflash.bin   -S -s

I have no warnings, but when I attach with gdb I either don't see my
code, and nothing happens again, execution just goes successively
until 0x04000000 reached.


-- 
With best regards,
Matwey V. Kornilov
http://blog.matwey.name
xmpp:address@hidden



------------------------------

_______________________________________________
Qemu-discuss mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/qemu-discuss


End of Qemu-discuss Digest, Vol 33, Issue 13
********************************************