Re: Technical support

[Thomas Huth]

On 24/03/2024 19.45, Luca Vajen wrote:

Hello,
I'm not sure if this is the right place to ask for help. I guess in the 
worst case you might get a laugh out of this. There's an old game I would 
like to play again and someone made a ready-to-play version using QEMU. See 
the corresponding link 
on https://werbespiel.blogspot.com/2010/07/tony-friends-new-adventures.html 
. That itself is handy, but the game runs too fast on my PC and I don't know 
how to slow it down. I didn't find an answer anywhere how to limit the 
speed. Does someone have an idea?


QEMU is a JIT emulator that normally tries always to go as fast as possible, 
so for emulating old software that is sensitive to timing, you might need 
another emulator instead.

However, there are also some few tricks that can be used to slow down QEMU:

1) Build QEMU with --enable-debug ... that turns off optimizations during
   compilation and thus emulation gets slower

2) Try running with "-accel tcg,one-insn-per-tb=on" (or "-singlestep" when
   you are using older QEMU binaries), that will disable the advantage of
   JIT and emulate each instruction separately, slowing down the emulation
   quite a bit, too.

 HTH,
  Thomas

Re: Directory does not fit in FAT16 (capacity 516.06 MB)

[Thomas Huth]

On 13/12/2023 13.51, Alberto Garcia wrote:

On Wed, Dec 13, 2023 at 01:27:49PM +0100, Narcis Garcia wrote:

A FAT16 partition (0x06) can be as large as 2 GiB


That's why I say that there's probably a limitation in the QEMU vvfat
driver.


Yes, it's hard-coded somewhere here:

https://gitlab.com/qemu-project/qemu/-/blob/v8.1.0/block/vvfat.c#L1195

Anyway, it's not recommended to use vvfat anymore since it's very old and 
unmaintained code. If possible, use something like usb-mtp or virtio-fs instead.


 Thomas

Re: How to start most minimal VM (no PCI) with a network to log in over SSH?

[Thomas Huth]

On Sat, 2023-09-09 at 11:53 +0200, Paul Menzel wrote:
> Dear QEMU folks,
> 
> 
> I’d like to start the most minimal VM possible, but still want to be 
> able to log in over SSH. With QEMU 7.2.1 the command below fails, as
> I 
> am passing an incompatible NIC model:
> 
>  $ qemu-system-x86_64 -M 
> microvm,x-option-roms=off,pit=off,pic=off,isa-serial=off,rtc=off 
> -enable-kvm -cpu host -m 32G -smp 32 -nodefaults -no-user-config 
> -nographic -device virtio-rng-device -chardev stdio,id=virtiocon0 
> -device virtio-serial-device -device virtconsole,chardev=virtiocon0 
> -drive id=root,file=debian.img,format=raw,if=none -device 
> virtio-blk-device,drive=root -nic user,model=virtio-net-pci -net 
> user,hostfwd=tcp::4-:22
>  qemu-system-x86_64: warning: hub 0 with no nics
>  qemu-system-x86_64: warning: netdev #net029 has no peer
>  qemu-system-x86_64: warning: requested NIC (anonymous, model 
> virtio-net-pci) was not created (not supported by this machine?)
> 
> What NIC model should be used instead?
> 
>  $ qemu-system-x86_64 -nic model=help
> 

IIRC "-nic model=help" only lists the PCI devices for some historical
reasons. You can get a list of all devices by running QEMU with "-
device help".

I've never tried it, so no clue whether it works, but you might want to
try:

 -netdev user,id=n1 -device virtio-net-device,netdev=n1

or:

 -netdev user,id=n1 -device ne2k_isa,netdev=n1

to get a NIC with the microvm machine.

 HTH,
  Thomas

Re: boot from usb-host device

[Thomas Huth]

On 10/08/2023 09.30, José Ramón Muñoz Pekkarinen wrote:

 Hi,

 I'm testing to boot a virtual machine from an
usb device on the host using usb-host device.
The bios seems not to find the usb device and
try alternatives methods to boot until all fail. Setting
-boot menu=on, the available options doesn't list
any usb drive. Is this somehow possible or am I
doing something terribly wrong? The virtual machine
command line follows:

/usr/bin/qemu-system-x86_64 -enable-kvm -M q35 \
-vga none -display gtk,gl=on -cpu host -smp 8,cores=8,threads=1 \
-m 4G -mem-path /dev/hugepages -L /usr/share/qemu -full-screen \
-global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 \
-device virtio-vga-gl \
-device qemu-xhci,id=xhci -device usb-tablet \
-device usb-host,vendorid=0x20a0,productid=0x4109 \
-device usb-host,vendorid=0x1050,productid=0x0407 \
-netdev user,id=user.0 -device virtio-net-pci,netdev=user.0 \
-device virtio-serial \
-chardev
socket,path=/tmp/tails-virtio-serial,server=on,wait=off,id=tails-virtio-serial
\
-device 
virtserialport,chardev=tails-virtio-serial,name=org.qemu.guest_agent.0

 The device to boot is the usb-host 20a0:4109.

 Thanks!


I've never tried, but you should maybe add a bootindex to the device that 
you want to boot from:


 -device usb-host,vendorid=0x20a0,productid=0x4109,bootindex=1

 HTH,
  Thomas

Re: Pinging test

[Thomas Huth]

On 03/08/2023 22.18, Swedha R wrote:

Hi team,
   I have RISCV linux up and running in qemu . But I can't able to ping test 
in that. Like ping google.com . It able to transmit but 
not able to receive.


 Hi!
There are multiple network backends and frontends in QEMU, so please specify 
how you are running QEMU when you're asking such questions, otherwise it is 
hard to tell what could be wrong. But if I had to guess:


https://wiki.qemu.org/Documentation/Networking#Enabling_ping_in_the_guest,_on_Linux_hosts

 HTH,
  Thomas

Re: How to solve: 'Please append a correct "root=" boot option' ?

[Thomas Huth]

On 24/04/2023 12.27, Freitas GDH wrote:

Hi Thomas,

Yes, I have The source code. What files may I verify?


Well, look for the file that creates the "fg_DIR_615_H1_ralink_rt3352_soc" 
machine. Are there any "pci" related things in there? Anything related to 
"scsi" ? Is it using any of the macros starting with "IF_" ? E.g. IF_SD, 
IF_VIRTIO, IF_IDE or IF_SCSI? ... that would be an indication what kind of 
device your machine supports.


 Thomas


Em sex., 21 de abr. de 2023 11:40, Thomas Huth <mailto:th...@redhat.com>> escreveu:


On 20/04/2023 13.53, Freitas GDH wrote:
 > Thank you Frank and Thomas !!
 >
 > Before use if=none I've tried:
 >
 > *-drive file=1.squashfs,if=virtio,format=raw,id=foo -device
 > virtio-blk-device,drive=foo *
 > /qemu-system-mipsel: -device virtio-blk-device,drive-foo: No
'virtio-bus'
 > bus found for device 'virtio-blk-device'/
 > and
 > *-drive file=1.squashfs,if=virtio,format=raw*
 > /qemu-system-mipsel: -drive file=1.squashfs,if=virtio,format=raw: No
'PCI'
 > bus found for device 'virtio-blk-pci'/
 >
 > After watch the Thomas video, I ran:
 > *-blockdev file,node-name=f1,filename=/home/fenix/files/1/1.squashfs \
 > -blockdev raw,node-name=q1,file=f1 \
 > -device virtio-blk,drive=q1 \*
 > /qemu-system-mipsel: -device virtio-blk,drive=q1: No 'PCI' bus found for
 > device 'virtio-blk-pci'/

That means that your machine does not support PCI, so you cannot use the
normal virtio devices.

Do you have the source code of that machine available somewhere? Looking at
that code is maybe the easiest way to find out which devices it supports...

   Thomas

Re: How to solve: 'Please append a correct "root=" boot option' ?

[Thomas Huth]

On 20/04/2023 13.53, Freitas GDH wrote:

Thank you Frank and Thomas !!

Before use if=none I've tried:

*-drive file=1.squashfs,if=virtio,format=raw,id=foo -device 
virtio-blk-device,drive=foo *
/qemu-system-mipsel: -device virtio-blk-device,drive-foo: No 'virtio-bus' 
bus found for device 'virtio-blk-device'/

and
*-drive file=1.squashfs,if=virtio,format=raw*
/qemu-system-mipsel: -drive file=1.squashfs,if=virtio,format=raw: No 'PCI' 
bus found for device 'virtio-blk-pci'/


After watch the Thomas video, I ran:
*-blockdev file,node-name=f1,filename=/home/fenix/files/1/1.squashfs \
-blockdev raw,node-name=q1,file=f1 \
-device virtio-blk,drive=q1 \*
/qemu-system-mipsel: -device virtio-blk,drive=q1: No 'PCI' bus found for 
device 'virtio-blk-pci'/


That means that your machine does not support PCI, so you cannot use the 
normal virtio devices.


Do you have the source code of that machine available somewhere? Looking at 
that code is maybe the easiest way to find out which devices it supports...


 Thomas

Re: How to solve: 'Please append a correct "root=" boot option' ?

[Thomas Huth]

On 20/04/2023 04.40, Freitas GDH wrote:

Hi there!

I'm using a customized qemu-4.0.0 with SOC RT3352 (implemented by Firmguide 
) in order to emulate D-Link 
DIR-615 firmware. Using an openwrt file I got a dtb file and compiled qemu 
successfully. But when I'm trying to emulate the firmware, I'm not able to 
identify the right mapping for my FS image file. I used two different 
squashfs files, one extracted from stock firmware and the other from openwrt 
lede-17.01.7 image. In both cases I got the same error. The following are 
the command syntax used.


//tmp/qemu-4.0.0/mipsel-softmmu/qemu-system-mipsel \
-D /dev/null \
-M fg_DIR_615_H1_ralink_rt3352_soc \
-kernel 
/home/fenix/firmguide/_lede-17.01.7-ramips-rt305x-dir-615-h1-squashfs-sysupgrade.bin.extracted/0.uimage \
-dtb 
/home/fenix/firmguide/_lede-17.01.7-ramips-rt305x-dir-615-h1-squashfs-sysupgrade.bin.extracted/_40.extracted/410.dtb,offset=0x410 \

-nographic \
-drive file=/tmp/dir-615_H1/lede-17.01.7_dir-615.squashfs,if=none,format=raw \
-append "root=/dev/vda"/


With "-drive ...,if=none,..." you only configure a *backend* for a block 
device, but it is not automatically wired to any of the emulated devices.
You need to know which hardware device in your emulated machine should be 
used as block device *frontend*.
Then you either have to use "-drive ...,if=ide,..." or "if=scsi" or 
"if=virtio" or whatever, or add an "id=xxx" parameter to the drive option 
and configure the device with "-device yyy,drive=xxx". It all depends on the 
implementation of the machine that you are using. No clue about that 
fg_DIR_615_H1_ralink_rt3352_soc machine, though, since it is not an upstream 
machine, I guess you have to look at the source code if there is no 
documentation available.


 HTH,
  Thomas

PS: If you feel lost in the QEMU parameter jungle, I recommend 
https://archive.fosdem.org/2018/schedule/event/vai_qemu_jungle/ ... block 
devices start around minute 25:23 in the presentation.



I used: vda, vda1, sda, sda1.

Piece of log:

[    1.544687] rt2880_wdt 1120.watchdog: Initialized
[    1.546636] NET: Registered protocol family 10
[    1.558513] NET: Registered protocol family 17
[    1.559810] bridge: automatic filtering via arp/ip/ip6tables has been 
deprecated. Update your scripts to load br_netfilter if you need this.

[    1.560308] 8021q: 802.1Q VLAN Support v1.8
[    1.564650] fdt: not creating '/sys/firmware/fdt': CRC check failed
*[    1.579213] VFS: Cannot open root device "vda" or unknown-block(0,0): 
error -6
[    1.579566] Please append a correct "root=" boot option; here are the 
available partitions:
[    1.580137] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)*

[    1.582285] Rebooting in 1 seconds..
[    3.551589] Reboot failed -- System halted


But if instead of /-drive /I use -/initrd/ the emulation runs successfully.
-initrd 0.cpio \
-append "console=ttyS0 nowatchdog nokaslr"

O also tried to create a cpio file from the squashfs files, but I got the 
same error 'cannot open root device...'.


Thank you !

Re: How to increase memory in a RISCV32 image? Stuck with 988MB

[Thomas Huth]

On 17/04/2023 19.21, Mikhail R. Gadelha wrote:

Hi qemu folks,

I'm using yocto to generate a riscv32 image but qemu seems to be ignoring 
the -m argument from the command line and forcing the image to run with 
988MB of RAM.


Is there any way I can increase it to 4G?

I'm using the following cmdline to start qemu:

qemu-system-riscv32 -nographic -machine virt -m 4G -smp 8 -bios 
/home/mgadelha/tools/poky/build/tmp/deploy/images/qemuriscv32/fw_jump.elf 
-kernel /home/mgadelha/tools/poky/build/tmp/deploy/images/qemuriscv32/Image 
-append "root=/dev/vda rw mem=4G" -drive 


That "mem=4G" part of the -append option looks suspicious ... have you 
already tried to boot without that, or to decrease it to a number that fits 
into 32-bit, e.g. "mem=3G" ?


 HTH,
  Thomas


id=disk0,file=/home/mgadelha/tools/poky/build/tmp/deploy/images/qemuriscv32/core-image-full-cmdline-qemuriscv32-20230415202008.rootfs.ext4,if=none,format=raw
 -device virtio-net-device,netdev=usernet -netdev 
user,id=usernet,hostfwd=tcp::2-:22 -device virtio-blk-device,drive=disk0 
-object rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0 -device virtio-tablet-pci -device virtio-keyboard-pci

Well, it actually doesn't start if I use -m 4G, but any value lower than 
that is fine.


Here's also the boot log: https://pastebin.com/b7ZEP659 



I see that the kernel prints:

[    0.00] Memory limited to 1024MB

so maybe it's a kernel limitation rather than qemu?

--

Mikhail Ramalho.

Re: hubport connectivity problems

[Thomas Huth]

On 27/03/2023 21.52, Eric Nichols (DirWiz) via wrote:

Long time user, first time poster...

My setup is simple.  Debian host running qemu 7.2.0 and 2 guest (Windows 
2010 workstation & 2022 server).  My goal is to setup a private guest only 
network (no connection to host) with hubport.


Based on the docs I've tried:
-netdev hubport,hubid=0,id=hub0 -device virtio-net-pci,netdev=hub0

There is also the second option of:
-nic hubport,hubid=0,model=virtio-net-pci

And also small mention that a hubport 0 will be setup if you just use a 
virtual adapter and don't connect it to anything:

-net nic,model=virtio-net-pci,macaddr=52:54:00:00:00:03

I did static IPs on both of the guests but can't ping or connect over TCP.
Any ideas?


hubport basically emulates a hub *within* one instance of QEMU. Hubport 
alone does not connect to any other QEMU (i.e. guest) instance. It's mostly 
a legacy concept from the early days of QEMU - and unless you want to 
connect multiple NICs of one guest together, you likely don't need it. (see 
also https://www.qemu.org/2018/05/31/nic-parameter/ for some more information).


If you want to connect two local guests via a local network, you could have 
a look at the "-netdev socket" option. For example, start one QEMU with 
"-nic socket,model=virtio-net-pci,id=net0,listen=:1234" and the other QEMU 
with "-nic socket,model=virtio-net-pci,id=net1,connect=:1234" and you should 
be able to see the network traffic of one guest on the interface of the 
other and vice versa.


 HTH,
  Thomas

Re: qemu modifies host audio sample rate with coreaudio backend to 44.1khz on startup

[Thomas Huth]

On 25/03/2023 18.24, Christian Schoenebeck wrote:

On Friday, March 24, 2023 8:38:25 PM CET Frank Carmickle wrote:

Greetings all,

Thank you Thomas for bringing this to the attention of folks who are in the 
know.

Thank you, Christian for explaining.

What I am finding is that qemu sets the host to 44.1k even though alsa dmix in 
the guest is set to 48k. What I wanted was to set the host to 96k and the guest 
to 96k. When I do that, by using audio midi setup for the host, and changing 
alsa dmix rate to 96k, after starting the guest, audio midi setup shows that 
the host is set to 44.1k.

When using the parameter Thomas mentioned, the host sample rate is changed to 
the designated.

Seems like alsa has a problem. I'll use Thomas's suggestion as a workaround, 
for now.


DMIX in ALSA is like mixengine in QEMU: a layer that automatically converts
audio format on the fly between incompatible sides (sample rate, channels,
etc.). That's used if the audio hardware does not support the desired audio
format natively.

You did not mention which audio frontend (the virtual audio hardware emulated
by QEMU for guest) you are using. I just made a quick test with the AC97
frontend and `aplay` a wav file on guest, and it used 48 kHz like the wav file
content, not 44.1 kHz.

@Thomas: I just realized that QEMU's audio frontend selection parameters are
not documented at all?


Yes, as I said, the documentation is really lacking here - I had to look at 
the sources to come up with the out.frequency=48000. I think if someone who 
knows the audio stuff in QEMU comes up with a patch for the documentation, 
that would be really appreciated.


 Thomas

Re: qemu modifies host audio sample rate with coreaudio backend to 44.1khz on startup

[Thomas Huth]

On 23/03/2023 21.03, Frank Carmickle wrote:

Greetings all,

Every time a qemu instance is run, the host systems audio hardware sample rate 
is set to 44.1khz. Is it possible to change this behavior, and if so, how?


 Hi,

not sure if I've got the question right, and I'm not an expert when it comes 
to QEMU audio, but I think you can set the playback frequency like this for 
example:


 qemu-system-x86_64 --audiodev alsa,id=a1,out.frequency=48000

... but seems like the QEMU documentation is really lacking here, so I might 
be wrong. Maybe Christian, Gerd or Marc-André could correct me in that case 
(now on CC:).


 HTH,
  Thomas

Re: Cross compilation of QEMU source code for ARM64

[Thomas Huth]

On 23/03/2023 19.30, Pedro Miguel Veiga de Almeida e Silva wrote:

Hello,

I am trying to cross compile the source code to deploy it in a xilinx 
ZCU106. But every time I execute the ./configure 
--target-list=aarch64-softmmu --enable-kvm and then make.


But the file that compiles is a X86.

Can you help me?


With --target-list you select the target that QEMU emulates later, not the 
host environment.


For cross-compiling, you need the --cross-prefix=... option of the configure 
script to set the prefix of your cross-compiler toolchain. For example, if 
your cross-compiler is called "arm-linux-gnueabi-gcc", you'd use:


 ./configure --cross-prefix=arm-linux-gnueabi-

Hope that helps,
  Thomas

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 14.01, Andrew Randrianasulu wrote:
...
Well, this language about "market" and "investment"  not just figures of the 
speech, sadly? Because paid developers work on  areas they paid to develop, 
by boss with big bucks.


Sorry for getting more explicit now, but: Can you please stop making such 
aggressive assertions which are obviously wrong and where you apparently 
have no clue about about?


If you'd followed the QEMU project, you'd know that there are very helpful 
people around, from all kind of companies, Linaro guys who help with 
reviewing and merging non-ARM patches, Red Hatters who help with BSD and 
Haiku patches, etc.


Anyway, if you're not happy with the way the project is evolving, then start 
contributing instead of grumbling.


 Thomas

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 12.04, Andrew Randrianasulu wrote:

Also, for CI thing may be lessen compiler optimization levels at least for 
some runs? And/or tweak ccache compression 


Please stop blindly making suggestions for our CI if you don't really know 
it (e.g. we don't use ccache). That's really not helpful. Thanks.


 Thomas

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 11.22, Andrew Randrianasulu wrote:



чт, 16 мар. 2023 г., 12:17 Andrew Randrianasulu <mailto:randrianas...@gmail.com>>:




чт, 16 мар. 2023 г., 11:31 Thomas Huth mailto:th...@redhat.com>>:

On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:
 > On 16/3/23 08:17, Andrew Randrianasulu wrote:
 >>
 >> чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé
mailto:phi...@linaro.org>
 >> <mailto:phi...@linaro.org <mailto:phi...@linaro.org>>>:
 >>
 >>     Hi Andrew,
 >>
 >>     On 16/3/23 01:57, Andrew Randrianasulu wrote:
 >>  > Looking at https://wiki.qemu.org/ChangeLog/8.0
<https://wiki.qemu.org/ChangeLog/8.0>
 >>     <https://wiki.qemu.org/ChangeLog/8.0
<https://wiki.qemu.org/ChangeLog/8.0>>
 >>  > <https://wiki.qemu.org/ChangeLog/8.0
<https://wiki.qemu.org/ChangeLog/8.0>
 >>     <https://wiki.qemu.org/ChangeLog/8.0
<https://wiki.qemu.org/ChangeLog/8.0>>>
 >>  >
 >>  > ===
 >>  > System emulation on 32-bit x86 and ARM hosts has been
deprecated.
 >>     The
 >>  > QEMU project no longer considers 32-bit x86 and ARM
support for
 >>     system
 >>  > emulation to be an effective use of its limited
resources, and thus
 >>  > intends to discontinue.
 >>  >
 >>  >   ==
 >>  >
 >>  > well, I guess arguing from memory-consuption point on 32
bit x86
 >>     hosts
 >>  > (like my machine where I run 32 bit userspace on 64 bit
kernel)

All current PCs have multiple gigabytes of RAM, so using a 32-bit
userspace
to save some few bytes sounds weird.


I think difference more like in 20-30% (on disk and in ram), not *few
bytes*. 



I stand (self) corrected on *on disk* binary size, this parameter tend to be 
~same between bash / php binaries from Slackware 15.0 i586/x86_64. I do not 
have full identical x64 Slackware setup for measuring memory impact.



Still, pushing users into endless hw upgrade is no fun:

https://hackaday.com/2023/02/28/repurposing-old-smartphones-when-reusing-makes-more-sense-than-recycling/
 >

note e-waste and energy consumption


Now you're mixing things quite badly. That would be an argument in the years 
before 2010 maybe, when not everybody had a 64-bit processor in their PC 
yet, but it's been now more than 12 years that all recent Desktop processors 
feature 64-bit mode. So if QEMU stops supporting 32-bit x86 environments, 
this is not forcing you to buy a new hardware, since you're having a 64-bit 
hardware already anyway. If someone still has plain 32-bit x86 hardware 
around for their daily use, that's certainly not a piece of hardware you 
want to run QEMU on, since it's older than 12 years already, and thus not 
really strong enough to run a recent emulator in a recent way.


 Thomas

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 09.07, Liviu Ionescu wrote:




On 16 Mar 2023, at 09:57, Liviu Ionescu  wrote:

I'm not targeting RPi2; there are a lot of RPi4 with less than 8GB RAM (most of 
them, actually), and even more RPi3, with even less RAM), and people prefer to 
continue using the 32-bit OS on them, which works quite fine;


Like it or not, as long as Raspberry does not explicitly deprecate the 32-bit 
OS, people will continue to use it, and for good reasons.

As of now, it is even 'Our recommended operating system for most users.':


I'd say "most users" != "the people who want to run QEMU here". If you 
really really want to run QEMU on such a system, you can also install a 
64-bit OS there.


Please also consider that we're only talking about marking the 32-bit arm 
hosts as deprecated in our docs right now. It will take another year (or 
maybe more) until the deprecation will turn into a real unsupported state. I 
assume by that point in time, more and more RPi users will have switched to 
a 64-bit OS instead.


 Thomas

Re: dropping 32-bit host support

[Thomas Huth]

On 16/03/2023 08.36, Philippe Mathieu-Daudé wrote:

On 16/3/23 08:17, Andrew Randrianasulu wrote:


чт, 16 мар. 2023 г., 10:05 Philippe Mathieu-Daudé >:


    Hi Andrew,

    On 16/3/23 01:57, Andrew Randrianasulu wrote:
 > Looking at https://wiki.qemu.org/ChangeLog/8.0
    
 > >
 >
 > ===
 > System emulation on 32-bit x86 and ARM hosts has been deprecated.
    The
 > QEMU project no longer considers 32-bit x86 and ARM support for
    system
 > emulation to be an effective use of its limited resources, and thus
 > intends to discontinue.
 >
 >   ==
 >
 > well, I guess arguing from memory-consuption point on 32 bit x86
    hosts
 > (like my machine where I run 32 bit userspace on 64 bit kernel)


All current PCs have multiple gigabytes of RAM, so using a 32-bit userspace 
to save some few bytes sounds weird.


(and in case you're talking about a very old PC that cannot be extened 
anymore, you're likely better off with an older version of QEMU anyway)




    If you use a 64-bit kernel, then your host is 64-bit :)



No, I mean *kernel* is 64 bit yet userspace (glibc, X , ...) all 32bit. 
So, qemu naturally will be 32-bit binary on my system.


This configuration is still supported!

Thomas, should we clarify yet again? Maybe adding examples?


There are two aspects here:

1) 32-bit KVM support - this won't be supported in the future anymore. Since 
running a 32-bit QEMU on a 64-bit kernel still uses the 32-bit KVM API, KVM 
also won't be possible anymore with a QEMU that has been compiled in 32-bit 
mode.


2) Compiling a 32-bit QEMU binary won't be officially supported anymore. We 
won't waste any more precious CI minutes on this (which is where we're 
struggling the most currently), and likely no active support for finding and 
fixing bugs. But I guess we won't actively disable this possibility 
(especially since we did not deprecate the corresponding 32-bit linux-user 
emulation yet, so the emulation code will mostly still stay around).


In the long run, we likely want to get rid of the separate compilation of 
the qemu-system-i386 binary, too, but that's still to be discussed. E.g. we 
could add a special run mode to the qemu-system-x86_64 instead that makes 
sure that the guest can only run in 32-bit mode.



    host: hardware where you run QEMU
    guest: what is run within QEMU

    Running 32-bit *guest* on your 64-bit *host* is still supported.


If the complete userspace is 32-bit, I'd rather consider it a 32-bit host.

[...] I also ran qemu-system-ppc on Huawei Matepad T8 (32 bit Android, 
too) for emulating old mac os 9. Yes, I can wait 10 min per guest boot. 
Fedora 36 armhf boots even slower on emulation!


Yes, but for such scenarios, you can also use older versions of QEMU, you 
don't need the latest and greatest shiny QEMU version.


Well, sometimes simple patch restores functionality. I patched for example 
olive-editor to run on 32 bit, and before this intel embree (raytracing 
kernels for Lux renderer). So, _sometimes_ it really not that costly. 
While if this CI thing really runs per-commit and thrown away each result 
... may be letting interested users to build things on their own machines 
(and share patches, if they develop them, publicly) actually good idea.


The problem is really that we don't have unlimited resources in the QEMU 
project. Currently we're heavily struggling with the load in the CI, but 
also pure man power is always very scarce. So at one point in time, you have 
to decide to say good bye to some old and hardly used features - at least to 
stop testing and actively supporting it. If you want to continue testing and 
fixing bugs for such host systems, that's fine, of course, but don't expect 
the QEMU developers to do that job in the future.


 Thomas

Re: What is the purpose for "none" machine?

[Thomas Huth]

On 23/01/2023 21.03, Peter Maydell wrote:

On Mon, 23 Jan 2023 at 18:07, Matwey V. Kornilov
 wrote:


пн, 23 янв. 2023 г. в 21:02, Peter Maydell :


On Mon, 23 Jan 2023 at 17:36, Matwey V. Kornilov
 wrote:

I am playing with qemu-system-avr currently.
I see that there is an "empty machine" called "none" in

  qemu-system-avr -M help

list.

Is it a real thing? I am failed to run any code with "none" machine.


It is mostly for the benefit of management layer code (eg libvirt)
that wants to probe capabilities of QEMU[*], and secondarily used
in some of QEMU's own test suite.  The 'none' machine has no CPU,
no devices and no RAM, which is why you can't run any code on it.


Thanks for the explanation. Is there a way to manually add CPU, RAM
and other devices in the command line if 'none' is used?


For a CPU and RAM, for some architectures where there is hotplug
CPU and hotplug RAM support that might be possible (definitely
not for AVR!) but I'm not sure if it's supported as an intended
use case. For other devices, generally not.


Some people really only need a plain machine with CPU and RAM for testing 
instructions. So I've improved the "none" machine a couple of years ago to 
be used as plain instruction set simulator, see:


 https://gitlab.com/qemu-project/qemu/-/commit/3964ec6c0b49e4c2fa3e48f

(that way we were able to get rid of the "dummy" m68k machine which had 
exactly the same purpose). It seems to be working with avr, too.


 Thomas

Re: What is the purpose for "none" machine?

[Thomas Huth]

On 23/01/2023 19.07, Matwey V. Kornilov wrote:

пн, 23 янв. 2023 г. в 21:02, Peter Maydell :


On Mon, 23 Jan 2023 at 17:36, Matwey V. Kornilov
 wrote:

I am playing with qemu-system-avr currently.
I see that there is an "empty machine" called "none" in

  qemu-system-avr -M help

list.

Is it a real thing? I am failed to run any code with "none" machine.


It is mostly for the benefit of management layer code (eg libvirt)
that wants to probe capabilities of QEMU[*], and secondarily used
in some of QEMU's own test suite.  The 'none' machine has no CPU,
no devices and no RAM, which is why you can't run any code on it.


Thanks for the explanation. Is there a way to manually add CPU, RAM
and other devices in the command line if 'none' is used?


It's doable on some targets, e.g. m68k. avr seems to be working, too:

- You can specify a CPU with the "-cpu" command line option
  (use "-cpu help" for a list)

- You can specify a RAM region with the "-m" command line option
  (it will be created at address 0)

- You can load some code with the "loader" device
  (see "-device loader,help" for information how to use it)

For example:

wget 
https://github.com/seharris/qemu-avr-tests/raw/master/free-rtos/Demo/AVR_ATMega2560_GCC/demo.elf


$ ./qemu-system-avr -M none -cpu avr6-avr-cpu -m 512 -d in_asm \
  -device loader,file=demo.elf 2>&1 | head -n 15

IN:
0x:  JMP   0x110


IN:
0x0110:  EOR   r1, r1
0x0112:  OUT   $63, r1
0x0114:  LDI   r28, 255
0x0116:  LDI   r29, 33
0x0118:  OUT   $62, r29
0x011a:  OUT   $61, r28
0x011c:  LDI   r16, 0
0x011e:  OUT   $60, r16
0x0120:  LDI   r17, 2

... of course you might also want to attach an avr GDB to QEMU to interact 
with the code, but I don't have such a GDB here right now, so no way to 
check whether that's working here or not.


 HTH,
  Thomas

Re: Query Max CPUs

[Thomas Huth]

On 09/01/2023 22.21, Colton Lewis wrote:

Is there a way to query the maximum number of CPUs suppoted by the
current emulator?

I found
https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg02109.html

That seems close to what I want, but the command isn't in the current
QMP reference manual.


You could use the "query-machines" QMP command - it returns a "cpu-max" 
information for each available machine type.



I'd also prefer not going through QMP if possible because my working
environment does not have the qmp-shell script handy.


If you don't mind parsing the QMP output manually, you can also simply run 
QEMU with "-qmp stdio" and then paste these two lines into the console:


{ "execute": "qmp_capabilities" }
{ "execute": "query-machines" }

 HTH,
  Thomas

Re: download kvm keynote slides

[Thomas Huth]

On 30/11/2022 05.00, Jiatong Shen wrote:

Hello community,

    Sorry in advance if this is not the right place to ask.. Where could I 
download kvm forum's keynote for the past 3 years? I googled but only found 
http://www.linux-kvm.org/page/KVM_Forum_2015 very old documents.


Hi, you likely best check the schedules of the conferences, most speakers 
uploaded their slides there:


https://kvmforum2020.sched.com/

https://kvmforum2021.sched.com/

https://kvmforum2022.sched.com/

... and if you cannot find the talk you're looking for there, I suggest to 
try youtube.com - most talks have been recorded and can be found there.


 Thomas

Re: VDE?

[Thomas Huth]

On 31/10/2022 09.42, Tomas By wrote:

On Mon, 31 Oct 2022 09:20:27 +0100, Thomas Huth wrote:

"-nic" does not have any help output, I think.


Yes it does (unless I misunderstand things), same text as -netdev.


Oh, that's interesting! Recent versions of QEMU only show an error message 
in that case. Seems like this regressed somewhere between QEMU v5.1.0 and 5.2.0.



That error message should not happen with "-nic", I think. Could you
provide your full command line to make it clear what happens here?


|qemu-system-i386 -hda disk.img -boot c -m 8 -device ne2k_isa -nic user


Ah, ok, so it's the "-device" option that is causing the problem here. If 
you want to use "-device", you've got to use -netdev instead of -nic, 
something like:


 -netdev user,id=n1 -device ne2k_isa,netdev=n1

The -nic option is a combination of -netdev and -device, so in your case, 
you could use this instead:


 -nic user,model=ne2k_isa

See also this page for more information:

 https://www.qemu.org/2018/05/31/nic-parameter/


If you urgently want to use VDE, then you likely have to compile it on
your own. Otherwise you could try tap (I'd recommend libvirt for
easier setup here),


Is there some example somewhere showing how to do that, using current
versions of the tools etc?


If you want to use tap and libvirt, maybe the easiest solution is to use 
"virt-manager" to define your machines. Otherwise have a try with the 
"socket" network backend, I think that could work in your case, too.


 Thomas

Re: VDE?

[Thomas Huth]

On 29/10/2022 15.49, Tomas By wrote:

On Sat, 29 Oct 2022 14:59:26 +0200, Tomas By wrote:

I note that the "vdeq" command says it is DEPRECATED, but have not
been able to find out what replaced it.



Also, when I try it, I get "invalid parameter 'vlan'", and there is no
"vlan" anywhere in my scripts.


The "vlan" parameter has been removed with QEMU 3.0, see:


https://qemu-project.gitlab.io/qemu/about/removed-features.html#net-vlan-x-removed-in-3-0

So your "vdeq" must be very out of date. No clue if there is newer 
replacement, though, since I've never used VDE. If you really want to use 
VDE, I suggest contacting the VDE author and ask there for a replacement.


 Thomas

Re: VDE?

[Thomas Huth]

On 29/10/2022 14.59, Tomas By wrote:

Hi all,

I'm using QEMU 4.2.1 (Debian 1:4.2-3ubuntu6.23), and am trying to set
up two or more guest instances with DOS, and an emulated network
(using IPX, but can switch to TCP/IP I guess), all on one Linux
machine.
> When I say "qemu-system-i386 -nic help", it does not list "vde" (or
anything similar) - does this mean I do not have VDE in the binary?


"-nic" does not have any help output, I think. But you can try "-netdev 
help" - if that does not list "vde", then your binary does not have VDE 
enabled, I think.



When I boot with "-nic user". Linux says "nic has no peer" but in DOS
the drivers load ok.


That error message should not happen with "-nic", I think. Could you provide 
your full command line to make it clear what happens here?



What is the easiest way forward? Do I need to download and compile
QEMU from source to get VDE?


If you urgently want to use VDE, then you likely have to compile it on your 
own. Otherwise you could try tap (I'd recommend libvirt for easier setup 
here), or if your guests do not need any connection to the outside, you 
could try to wire them up via the "socket" backend instead, e.g. run one 
QEMU with:


 -nic socket,listen=:11122

and the second QEMU with:

 -nic socket,connect=:11122

 HTH,
  Thomas

Re: for some reason qemu.git fails with kvm?

[Thomas Huth]

On 17/10/2022 08.57, Andrew Randrianasulu wrote:



пн, 17 окт. 2022 г., 09:40 Thomas Huth <mailto:th...@redhat.com>>:


On 15/10/2022 20.32, Andrew Randrianasulu wrote:
 > qemu-system-i386 --version            QEMU emulator version 7.1.50
 > (v7.1.0-987-g2ba341b369-dirty)
 >
 > error message
 >
 > qemu-system-i386 -display none -cdrom
/mnt/sdb1/SLAX-01-11-2020-test0.iso
 > -enable-kvm                         qemu-system-i386: Could not install
 > MSR_CORE_THREAD_COUNT handler: Success

Why are you using qemu-system-i386 ? Are you still running on a 32-bit host
system?

yes 32 bit Slackware userspace , but on 64-bit kernel


Linux slax 5.19.8-x64 #1 SMP PREEMPT_DYNAMIC Thu Sep 8 20:29:55 MSK 2022 
x86_64 AMD FX(tm)-4300 Quad-Core Processor AuthenticAMD GNU/Linux


I reverted commit introducing this message and now kvm works 


OK, so that's 
https://gitlab.com/qemu-project/qemu/-/commit/37656470f67398dd1010 , right?


Maybe Alex Graf can help here (added to the recipients list now). At least 
there is a bug in the error reporting - the if-statement checks "r" but the 
error_report() uses "ret" (which is wrong here).


 Thomas

Re: for some reason qemu.git fails with kvm?

[Thomas Huth]

On 15/10/2022 20.32, Andrew Randrianasulu wrote:
qemu-system-i386 --version            QEMU emulator version 7.1.50 
(v7.1.0-987-g2ba341b369-dirty)


error message

qemu-system-i386 -display none -cdrom /mnt/sdb1/SLAX-01-11-2020-test0.iso 
-enable-kvm                         qemu-system-i386: Could not install 
MSR_CORE_THREAD_COUNT handler: Success


Why are you using qemu-system-i386 ? Are you still running on a 32-bit host 
system?
If not, i.e. if you are using a regular 64-bit Linux distro, I think you 
should use qemu-system-x86_64 instead - I hope that works better.
(but the error message "Success" is very weird indeed, I have to admit ... 
maybe there's a bug in the 32-bit build somewhere...)


 Thomas

Re: If your networking is failing after updating to the latest git version of QEMU...

[Thomas Huth]

On 29/09/2022 04.32, Jason Wang wrote:

On Thu, Sep 29, 2022 at 1:06 AM Philippe Mathieu-Daudé  wrote:


On 28/9/22 10:27, Thomas Huth wrote:


... it might have happened due to the removal of the "slirp" submodule
from the git repository. For example if you see an error message like this:

   Parameter 'type' expects a netdev backend type

this likely means that the "user" mode backend type is not available in
your binary anymore. To fix it, simply install "libslirp-devel" (or
libslirp-dev or however it is called) from your OS distribution and
recompile.


Thanks for the hint Thomas. I'm afraid many developers will miss your
email.

Jason, Marc-André, could we improve the buildsys check or display
a more helpful information from the code instead?


It looks to me we need to improve the build.


I'm not sure there is anything to improve in the build system - 
configure/meson.build are just doing what they should: Pick the default 
value for "slirp" if the user did not explicitly specify "--enable-slirp".


But the error message is not very helpful. It should rather say something 
like (partly suggested by Daniel in IRC yesterday already):


 Type 'user' is not a supported netdev backend by this QEMU build. Please 
check the spelling or whether it has been enabled at compilation time.


... or something like this.

Someone interested to write a patch?

 Thomas

If your networking is failing after updating to the latest git version of QEMU...

[Thomas Huth]

... it might have happened due to the removal of the "slirp" submodule from 
the git repository. For example if you see an error message like this:


 Parameter 'type' expects a netdev backend type

this likely means that the "user" mode backend type is not available in your 
binary anymore. To fix it, simply install "libslirp-devel" (or libslirp-dev 
or however it is called) from your OS distribution and recompile.


See also the commit message here:
 https://gitlab.com/qemu-project/qemu/-/commit/5890258aeeba303704

 Thomas

Re: VNC support is disabled

[Thomas Huth]

On 07/07/2022 01.29, Vishesh Tanksale wrote:

Hello,

I installed qemu using brew on my mac running macOS Monterey 12.4. I am not 
able to run a VM with VNC. I get following error message


$ qemu-system-x86_64 -vnc :0
qemu-system-x86_64: -vnc :0: VNC support is disabled


That message means that the VNC code has not been compiled into the binary.


Can anyone please help me enable VNC support?


You need to get a different binary that has VNC support compiled in (no clue 
where to get that for macOS, though).


 HTH,
  Thomas

Re: Dual Core MicroBlazer CPU emulation with QEMU (from QEMU.org)

[Thomas Huth]

On 01/07/2022 17.07, Charlu, Srinivasa [US] (DS) wrote:

Hello Sir

1. Does your QEMU support the emulation of the above CPU ?


QEMU has support for some Microblaze CPUs, see e.g.:

 https://wiki.qemu.org/Documentation/Platforms/MicroBlaze

Not sure whether that's what you're looking for, though (it's Microblaze, 
not MicroBlazeR).



2. Why this question ?

MicroBlazer CPU is not explicitly listed as being supported for emulation in 
the “QEMU System Emulator Target” section  of your documentation at


https://www.qemu.org/docs/master/system/targets.html#system-targets-ref 


Documentation is still lacking in quite a lot of places... Patches for 
improvement are certainly welcome ;-)


 Thomas

Re: API to change the vendor of IDE disk

[Thomas Huth]

 Hi!

On 01/07/2022 10.18, Alex wrote:
...

Here is my questions:


Q1: How to change the vendor-name of a IDE disk?

Is there any API(s) to config it?

I can't find the way from libvirt-doc.

​In Qemu code, I seems that "QEMU HARDDISK" is just by default, and 
it's configurable.


I think you can specify the model string when you run QEMU directy, e.g.:

 qemu-system-x86_64 -device ide-hd,model=XYZ ...

Whether that's somehow configurable via libvirt, too, you should better ask 
that question on the libvirt mailing list instead, I think.


 Thomas

Re: PS/2 keyboard emulation in QEMU vs. SCO 5 guest

[Thomas Huth]

On 04/06/2022 00.41, Frantisek Rysanek wrote:

Dear fellow tinkerers,

as an academic exercise (will need to tackle licensing if this turns
out technically feasible) I'm teasing an image of SCO OpenServer
5.0.6 in a QEMU+KVM VM (QEMU 5.2 on Debian 11).


QEMU 5.2 is rather old already - and there have been quite a bit of changes 
in the ps2 keyboard code during the last year, e.g. also this one here which 
adds a command line switch for old software:


 https://gitlab.com/qemu-project/qemu/-/commit/d1e45668d2128b064e

So I'd suggest that you try with QEMU v7.0 first to see whether that makes a 
difference?


 HTH,
  Thomas


The disk image is effectively a backup copy of an old SCO-based PC
box that is starting to have HW issues, and the existing software
cannot be reinstalled and it would make sense to move the software =
OS + apps "en bloc" into a VM.

On ancient bare metal, the disk boots just fine, I can log in and
everything works.

When I connect that same disk to a QEMU VM, OpenServer does detect
the emulated IDE disk controller, does detect the system disk and
rattles its heads a little, and then the VGA console asks for booting
into the single-user runlevel (requiring a root password), or a
CTRL+D to continue booting normally.

The trouble is, that in the VM, at this point the keyboard no longer
responds. The NumLock LED on the keyboard is responsive, probably
owing to the host OS (Debian) that keeps living. But, I cannot enter
a root password or try a CTRL+D.

In the initial "laundry list of hardware detected", the OpenServer
does report a PS/2 keyboard controller at ISA at a standard address.
But, when the request for CTRL+D appears, the OpenServer in a VM no
longer responds to my keyboard.

I'm a fan of QEMU - owing to its large set of configurable options.
Interestingly to me, I haven't found a single option related to the
PS/2 KB controller hardware... probablly because there's nothing to
tweak about it. Any suggestions what else could help?

Frank

Re: Seeking Help Installing Qemu-7.0.0

[Thomas Huth]

On 01/06/2022 06.55, Dennis Newbold wrote:
The immediate problem is that when I download the tarball and untar it per 
the instructions,

then cd to qemu-7.0.0 and do "./configure" I pretty quickly get:

Using './build' as the directory for build output

ERROR: Cannot find Ninja

I do not know what "Ninja" is.  ./configure --help is not particularly 
helpful, and the web documentation does not even mention the word "ninja" 
until it is talking about makefiles.
So ... if anyone knows where "Ninja" is or how I can get it, I would be 
appreciative.


The context / environment is that I am running on Centos 8.


You likely need:

 yum install ninja-build

We've got some hints here (which is not that obvious to find, I have to admit):


https://wiki.qemu.org/Hosts/Linux#Fedora_Linux_.2F_Debian_GNU_Linux_.2F_Ubuntu_Linux_.2F_Linux_Mint_distributions

 HTH,
  Thomas

Re: Custom DNS for a VM

[Thomas Huth]

On 26/05/2022 12.01, Narcis Garcia wrote:

Is it possible to specify an explicit DNS IP for a VM in user mode networking?

For example, host uses 1.2.3.4 as nameserver at /etc/resolv.conf
And I want a user mode VM makes queries to a different nameserver.

Context: Qemu 5.2.0 in Debian 11 host. All command-line.


I've never tried, but -netdev user has a "dns" option, so have you tried 
something like already:


 qemu-system-... -nic user,dns=8.8.8.8

?

 Thomas

Re: Physical USB port addressing

[Thomas Huth]

On 25/03/2022 19.13, Narcis Garcia wrote:

Some versions ago I could specify a host plugged device with this:
-usbdevice host:2001:3c17
but now I don't find a syntax that works for me (I also wish to ignore which 
physical port is device connected to):


$ lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 034: ID 2001:3c17 D-Link Corp. DWA-123 Wireless N 150 
Adapter(rev.A1) [Ralink RT3370]

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ qemu-system-x86_64 --version
QEMU emulator version 5.2.0 (Debian 1:5.2+dfsg-11+deb11u1)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
$ qemu-system-x86_64 (...) -device usb-host,vendorid=2001,productid=3c17
qemu-system-x86_64: -device usb-host,vendorid=2001,productid=3c17: No 
'usb-bus' bus found for device 'usb-host'


That error message means that there isn't a USB host controller defined for 
your guest. Try to add an additional "-device qemu-xhci" or something 
similar before the "-device usb-host,..." in your command line.


 HTH,
  Thomas

Re: how to obtain qemu changlogs

[Thomas Huth]

On 09/02/2022 03.25, Jiatong Shen wrote:

Hello community,

    I am trying to find new changelogs for each release. I find there is a 
site (https://wiki.qemu.org/ChangeLog/6.1 
) for it, but looks like it does not 
contain every changes. for example, 
https://github.com/qemu/qemu/commit/c56ac27d2ad583aa2db5382bb510a33b638a4ab5 
 
this commit which supports rbd device to write zeros is not included. May I 
ask how change log is generated? Thank you.


You can either browse the history here:

 https://gitlab.com/qemu-project/qemu/-/commits/master

or use the "git" tool to clone the repository to your hard disk, then you 
can browse the history with "git log" or tools like "gitk".


 HTH,
  Thomas

Re: os x resolution only 800x600

[Thomas Huth]

On 26/01/2022 14.11, Pascal wrote:

hi,
may be with -device VGA,edid=on,xres=1280,yres=720
regards.


You could also try with: -g 1800x1080

That seems to provide a bigger screen for the firmware, at least. It does 
not seem to work right with a width of 1920, though.


 Thomas


Le mer. 26 janv. 2022 à 13:53, chuck > a écrit :


Hi all

I installed ubuntu qemu and leopard on the virt disk

starting the powermac always displays 800x600.

startup command:

qemu-system-ppc -L pc-bios -boot c -M mac99,via=pmu -m 1024 -hda
macos.qcow2 -device VGA,edid=on -display gtk

i tried with

-display -vga

with  and without -device VGA,edid=on (both -display gtk / vga)

display preferences stay 800x600

switching to fullscreen does not change it

how can i change the display to 1920x1080.

thx for any help in this matter.

chuck

Re: modify NetdevUserOptions through QMP in QEMU 6 - how?

[Thomas Huth]

On 15/12/2021 04.31, Jason Wang wrote:

On Tue, Dec 14, 2021 at 10:53 PM Michael S. Tsirkin  wrote:


On Mon, Dec 13, 2021 at 09:02:15AM +0100, Thomas Huth wrote:

  Hi!

On 10/12/2021 18.02, Alexander Sosedkin wrote:

With QEMU 5 I could totally issue a QMP netdev_add
with the same ID to adjust the NetdevUserOptions I want,
such as restrict or hostfwd. No deleting needed,
just a netdev_add with what I want changed as a param.


I'm a little bit surprised that this worked, since AFAIK there is no code in
QEMU to *change* the parameters of a running netdev... likely the code added
a new netdev with the same ID, replacing the old one?


With QEMU 6 it started failing, claiming the ID is already used.
And if I do netdev_del + netdev_add, I just lose connectivity.
What's even stranger, I still see old netdev attached in info network:


netdev_del {'id': 'net0'}

{}

human-monitor-command {'command-line': 'info network'}

virtio-net-pci.0:
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
   \ net0: index=0,type=user,net=10.0.2.0,restrict=off


I think that's "normal" - there used to be problems in the past that the
devices (virtio-net-pci in this case) did not like the netdevs to be removed
on the fly. So the netdevs are kept around until you remove the device, too
(i.e. issue a device_del for the virtio-net-pci device).


netdev_add {'type': 'user', 'id': 'net0', 'restrict': False, 'hostfwd': 
[{'str': 'tcp:127.0.0.1:58239-:22'}]}

{}

human-monitor-command {'command-line': 'info network'}

unseal: virtio-net-pci.0:
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
   \ net0: index=0,type=user,net=10.0.2.0,restrict=off
net0: index=0,type=user,net=10.0.2.0,restrict=off

What's the correct QMP command sequence to modify NetdevUserOptions?


AFAIK there is no way to modify running netdevs - you'd have to delete the
netdev and the device, and then add both again. But I might have missed
something here, so I CC:-ed some people who might be more familiar with the
details here.

  Thomas



Please CC me on replies.



Wow this really goes to show how wide our feature matrix is.

Yes it's probably an unintended side effect but yes it
did work it seems, so we really should not just break it
without warning.


Probably this one:

commit 831734cce6494032e9233caff4d8442b3a1e7fef
Author: Markus Armbruster 
Date:   Wed Nov 25 11:02:20 2020 +0100

 net: Fix handling of id in netdev_add and netdev_del



Jason, what is your take here?


I might be wrong, but I agree with Thomas. Adding a netdev with the
same ID looks wrong, if it works, it looks like a bug. 


It certainly calls for trouble as soon as you try to delete the netdev again 
- does it delete the first (inactive) instance? Does it delete the second 
active one? Does it delete both? (Otherwise it will leave a dangling 
instance behind) ...
So if changing netdev parameters on the fly is something that we want, we 
should implement this properly instead indeed, and not via such an 
accidental bug.


 Thomas

Re: modify NetdevUserOptions through QMP in QEMU 6 - how?

[Thomas Huth]

 Hi!

On 10/12/2021 18.02, Alexander Sosedkin wrote:

With QEMU 5 I could totally issue a QMP netdev_add
with the same ID to adjust the NetdevUserOptions I want,
such as restrict or hostfwd. No deleting needed,
just a netdev_add with what I want changed as a param.


I'm a little bit surprised that this worked, since AFAIK there is no code in 
QEMU to *change* the parameters of a running netdev... likely the code added 
a new netdev with the same ID, replacing the old one?



With QEMU 6 it started failing, claiming the ID is already used.
And if I do netdev_del + netdev_add, I just lose connectivity.
What's even stranger, I still see old netdev attached in info network:


netdev_del {'id': 'net0'}

{}

human-monitor-command {'command-line': 'info network'}

virtio-net-pci.0:
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
  \ net0: index=0,type=user,net=10.0.2.0,restrict=off


I think that's "normal" - there used to be problems in the past that the 
devices (virtio-net-pci in this case) did not like the netdevs to be removed 
on the fly. So the netdevs are kept around until you remove the device, too 
(i.e. issue a device_del for the virtio-net-pci device).



netdev_add {'type': 'user', 'id': 'net0', 'restrict': False, 'hostfwd': 
[{'str': 'tcp:127.0.0.1:58239-:22'}]}

{}

human-monitor-command {'command-line': 'info network'}

unseal: virtio-net-pci.0:
index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
  \ net0: index=0,type=user,net=10.0.2.0,restrict=off
net0: index=0,type=user,net=10.0.2.0,restrict=off

What's the correct QMP command sequence to modify NetdevUserOptions?


AFAIK there is no way to modify running netdevs - you'd have to delete the 
netdev and the device, and then add both again. But I might have missed 
something here, so I CC:-ed some people who might be more familiar with the 
details here.


 Thomas



Please CC me on replies.

Re: ppc64 XER potentially ignored/not setting

[Thomas Huth]

On 30/10/2021 19.19, Kyle Lehman wrote:

Hello all,

I work with the libre-soc team in the testing area.  Recently I have started 
on writing an interface that uses qemu as another means to verify our 
results from our own simulations against qemu.


The basic workflow I have set up is:

1. Take a test (which are usually one or two instructions, along with a 
supplied list of registers)


2. Compile it as a bin (no loader, nothing but the compiled instructions), 
launch qemu along with gdb, set registers, PC, etc. via gdb


3. Step the instructions, extract registers with gdb and compare them to our 
own results


This works fairly well for int registers and from what I can tell so far the 
CR.  However, and I must apologize if this is somewhat beyond the scope of 
what qemu can do since I'm basically treating it as a finite state machine 
for this...on tests that use or would cause a change in the XER: so, ca, ov 
are ignored.


Launching as (built from latest master):
qemu-system-ppc64 -machine powernv9 -cpu power9 -nographic -s -S -m 
size=1024 -kernel test_path.bin


Instruction of test:
sraw 3, 1, 2  : 7c 23 16 30 (big endian)
r1 = 0x82345678
r2 = 8

Upon execution r3 is set correctly to 0xff823456, however ca is not 
set within the XER when it should be.


Could you reproduce the issue with a stand alone binary, too? ... it would 
be interesting to know whether the problem is in the GDB interface or in the 
emulation part...


 Thomas


There is another test that is a little more involved, which will actually 
use the XER only *if* I execute the instruction twice by setting the PC back 
to it again.  I can provide that if needed.


Regards,
Kyle

Re: Guest Ubuntu 18.04 fails to boot with -serial mon:stdio, cannot find ttyS0.

[Thomas Huth]

On 11/11/2021 17.10, Peter Maydell wrote:

On Mon, 8 Nov 2021 at 18:05, David Fernandez  wrote:


../configure \



--enable-lto \


Does disabling LTO make a difference? That's about the only
thing in the configure options that stands out as maybe
making a difference.


Please don't use LTO on non-x86 hosts, there are some known problems with 
these optimizations (though the symptoms look rather differently to what has 
been described here).


 Thomas

Re: Unable to boot Fedora LiveCD from USB pendrive with qemu-system

[Thomas Huth]

On 07/11/2021 16.30, Marcin Zajączkowski wrote:

Hi. Having some (dracut-related) issues with a Fedora LiveCD installed
on a pendrive, I wanted to play with it using qemu instead of a real
computer. Unfortunately, while the pendrive boot fine in real, with
qemu, I ended up with "Booting from Hard Drive..." displayed and 2
vCores working on 100% for several minutes (until I interrupted it).
Most likely, it is a problem with the way I try to achieve that:


sudo qemu-system-x86_64 -enable-kvm -m 4196 -drive 
file=/dev/sdb,format=raw,index=0,media=disk -boot menu=on


or more "dangerous" variant:

sudo qemu-system-x86_64 -enable-kvm -m 4196 -hda /dev/sdb -boot menu=on


IIRC that will attach the disk as an IDE drive to your guest. And I guess 
the initrd of your guest does not contain the right kernel modules for this 
interface.



What could be wrong with that approach? What is the best way to boot a
VM using a bootable disk connected as a USB device (here recognized as
/dev/sdb)?


Not sure, but you could try to attach it as (emulated) USB device to your 
guest, too, by using something like:


 -drive if=none,id=d1,file=... -device usb-storage,drive=d1

 HTH,
  Thomas

Re: Cross compile QEMU guest agent for windows on Linux server

[Thomas Huth]

On 17/09/2021 08.01, Jiatong Shen wrote:

Hello community,

    I am trying to build qemu guest agent for windows on a linux server, but 
I do not know how to start.. Could you give me references to guide me 
through the building process? Thank you.


Have a look here:

 https://wiki.qemu.org/Hosts/W32#Cross_builds

 HTH,
  Thomas

Re: QEMU boot kernel for ppc e300c3 problem

[Thomas Huth]

On 06/09/2021 09.40, Ali Vatankhah wrote:

Thank you Thomas for your reply.
 > You definitly need to select the right CPU type, too. So for your case,
 > you'd need to add the "-cpu e300c3" command line switch
  Also added this option but nothing changed and the command does not print 
anything.

 > But the CPU is only a part of the hardware, you also need to select a
 > supported board with the "-M" command line parameter
  How can I add a machine to Qemu for this CPU? I have a real MPC8308 board 
and am really interested in contributing to Qemu.
and another question, is it required to specify a machine type? I built a 
kernel for Powerpc g4 (7400) with the same Yocto (standard qemuppc machine) 
and Qemu runs the kernel without specifying cpu or machine, although Qemu 
supports PowerPC 7400 (g4) and a machine that uses this CPU (mac99):

qemu-system-ppc -kernel vmlinux -nographic


If you don't specify a machine type, QEMU uses a default machine. Run with 
"-M help" and look for the word "default" in the output. For 
qemu-system-ppc, it's the g3beige machine, which is likely compatible enough 
with the kernel that you've built.


 Thomas

Re: QEMU boot kernel for ppc e300c3 problem

[Thomas Huth]

On 04/09/2021 12.59, Ali Vatankhah wrote:
I am new to QEMU. I built a Linux kernel 4.14 and rootfs for MPC8308 (this 
CPU has e300c3 ppc core with Yocto (thud version) and it works on real 
hardware well.

When I run this command to run kernel with QEMU:

qemu-system-ppc -kernel vmlinux.bin -nographic

it prints this output and hangs up with 100% CPU usage on one CPU core:

 >> =
 >> OpenBIOS 1.1 [Mar 16 2021 08:16]
 >> Configuration device id QEMU version 1 machine id 2
 >> CPUs: 1
 >> Memory: 128M
 >> UUID: ----
 >> CPU type PowerPC,750


You definitly need to select the right CPU type, too. So for your case, 
you'd need to add the "-cpu e300c3" command line switch. See "-cpu help" for 
a complete list.


But the CPU is only a part of the hardware, you also need to select a 
supported board with the "-M" command line parameter. See "-M help" for a 
list. I don't think that QEMU supports any machine that features the e300 
CPU, so your case likely does not work. You could try "-M ppce500", maybe 
you're lucky and that works, too, but I guess it will rather crash instead.


 Thomas

Re: change vnc password

[Thomas Huth]

On 16/08/2021 13.53, Jiatong Shen wrote:

Hello,

I am trying to change the vnc password without shutting down the running 
virtual machine. And the problem is that virtual machine does not have a 
password.. Is it possible to change its password? Thank you.


If you've got a HMP monitor open, you could use the "change vnc password" 
command, see:


 https://qemu-project.gitlab.io/qemu/system/monitor.html#commands

 HTH,
  Thomas

Re: fbdev2

[Thomas Huth]

On 11/08/2021 23.38, Kjell via wrote:

Howdy,

I hate to ask stupid questions in the wrong places, but I just can't find 
anything and it puzzles me. Forgive me any ignorance too please.


Is it possible, or would it be, to be able to run qemu (qemu-kvm) without X 
in the framebuffer using the same fbdev2 option that mplayer uses or in a 
similar way?


I never tried, but as far as I know, the SDL library has support for 
directfb, so maybe "-display sdl" is what you're looking for?


 Thomas

Re: Disable scsi disk requests in QEMU when using virtio-blk device

[Thomas Huth]

On 18/07/2021 15.37, Arnabjyoti Kalita wrote:

Hello all,

Is it possible to disable scsi disk requests being generated by the
guest when using a virtio-blk device?

I am starting the guest in KVM mode using the below command line-

sudo ./qemu-system-x86_64 -m 1024 --machine pc-i440fx-2.5 -cpu
qemu64,-kvmclock,-kvm_pv_eoi
-enable-kvm -netdev tap,id=tap1,ifname=tap0,script=no,downscript=no
-device virtio-net-pci,netdev=tap1,mac=00:00:00:00:00:00 -object
filter-replay,id=replay,netdev=tap1
-drive 
file=~/os_images_for_qemu/ubuntu-16.04-desktop-amd64.qcow2,format=qcow2,if=none,id=img-direct
-device virtio-blk-pci,drive=img-direct


Try to replace the last line with:

 -device virtio-blk-pci,drive=img-direct,scsi=off

Generally, you can see a list of valid options for a device by running QEMU 
with something like:


 qemu-system-x86_64 -device virtio-blk-pci,help

 HTH,
  Thomas

Re: This QEMU does not support vmvga?

[Thomas Huth]

On 03/07/2021 02.21, Jacob Green wrote:
     Hello, so to elaborate on the subject, I am trying to understand why I 
cannot select the vmvga device and start my VM, I am running CentOS7 with 
extras enabled, and the QEMU version is

"# /usr/libexec/qemu-kvm --version
QEMU emulator version 2.12.0 (qemu-kvm-ev-2.12.0-44.1.el7_8.1)"
My domain configuration for video is as follows and virsh edit seems to like it.

     
       
       function='0x0'/>

     

The error message I receive when starting the VM is below.

"virsh start mydomain
error: Failed to start domain mydomain
error: unsupported configuration: this QEMU does not support 'vmvga' video 
device"


So I guess I'll start with the obvious, is the QEMU version too old? I 
thought vmvga support was added in like 0.10 or something.


The "qemu-kvm" from the "qemu-kvm-ev" package has many devices disabled 
which are rather badly maintained and thus could be a security risk in 
serious virtualization environments.


But why do you need "vmvga" at all? Can't you use one of the other available 
VGA cards like stdvga instead?


 Thomas

Re: Networking in Qemu with Xilinx-zcu102 machine

[Thomas Huth]

On 08/06/2021 19.09, asif siddiqui wrote:

Hello All,

I am working on the networking between my host OS linux and guest OS 
QNX(Running on top of qemu). I have an interface xzynq0 in my guest OS with 
a static/dynamic IP address.


I am executing the qemu command as follows -

qemu-system-aarch64 -M xlnx-zcu102 -m 8G -serial mon:stdio -display none 
-device loader,file=QNX_IFS.bin,cpu-num=0 -netdev 
bridge,br=virbr0,id=net0,helper=/usr/lib/qemu/qemu-bridge-helper -nographic 
  -global xlnx,zynqmp-boot.cpu-num=0 -global xlnx,zynqmp-boot.use-pmufw=true


Looking at your command line, it seems like you don't connect the "net0" 
netdev to anything on the guest side. -netdev only configures the host side 
network interface, but not the network adapter in the guest. See also:


 https://www.qemu.org/2018/05/31/nic-parameter/

Thus you might want to try "-nic" instead of "-netdev", but as far as I can 
see, the xlnx-zcu102 does not have any NIC on board by default? Maybe you 
could attach a virtio-net device with "-device", but I'm not sure whether 
that machine supports such devices...


 Thomas

Re: Cannot boot from emulated usb key if machine contains an emualted hard disk

[Thomas Huth]

On 17/05/2021 22.10, Paul Dufresne wrote:

If I do:
qemu-system-i386 -m 64M -drive node-name=erika,file=FD13FULL.img,format=raw 
-usb -device usb-storage,drive=erika

I get:
qemu-system-i386: -device usb-storage,drive=erika: Conflicts with use by 
ide0-hd0 as 'root', which does not allow 'write' on erika


I am able to boot from my emulated usb key (as if it is an hard drive) by doing:
qemu-system-i386 -m 64M -blockdev 
node-name=erika,driver=file,filename=FD13FULL.img -usb -device 
usb-storage,drive=erika


If I do:
qemu-system-i386 -m 64M -blockdev 
node-name=erika,driver=file,filename=FD13FULL.img -usb -device 
usb-storage,drive=erika -drive file=hd.img,format=raw
boot failed, not a bootable disk... I think because it try to boot from 
hd.img, which is a freshly created disk image (so with no system yet).


I may try to change index:
qemu-system-i386 -m 64M -blockdev 
node-name=erika,driver=file,filename=FD13FULL.img -usb -device 
usb-storage,drive=erika -drive file=hd.img,format=raw,index=3

Same error: boot failed, not a bootable disk


To specify a boot priority, the right parameter is called "bootindex", and 
you should it attach to the usb-storage device, e.g.:


 ... -device usb-storage,drive=erika,bootindex=1 

I hope that helps!

 Thomas

Re: Switching to the GitLab bug tracker

[Thomas Huth]

On 05/05/2021 11.55, Stefano Garzarella wrote:

On Tue, May 04, 2021 at 12:20:03PM +0200, Philippe Mathieu-Daudé wrote:

On 5/4/21 10:43 AM, Stefan Hajnoczi wrote:

On Mon, May 03, 2021 at 01:16:51PM +0200, Thomas Huth wrote:

As you might have already noticed by some other mails on the qemu-devel
mailing list, we are in progress of switching our bug tracking tool from
Launchpad to Gitlab. The new tracker can now be found here:

 https://gitlab.com/qemu-project/qemu/-/issues


Thank you for doing this, Thomas!

1) We likely won't have the possibility anymore to automatically send 
e-mail

notifications for new bugs to the qemu-devel mailing list. If you want to
get informed about new bugs, please use the notification mechanism from
Gitlab instead. That means, log into your gitlab account, browse to

 https://gitlab.com/qemu-project/qemu

and click on the bell icon at the top of the page to manage your
notifications, e.g. enable notifications for "New issues" there.


All maintainers and most regular contributors should follow the issue
tracker so that QEMU developers are aware of new issues. Please do this!

An alternative mechanism is the RSS/Atom feed available by clicking the
"Subscribe to RSS feed" button left of the "New issue" button here:

  https://gitlab.com/qemu-project/qemu/-/issues


You can also subscribe to labels of interest [*] going to
https://gitlab.com/qemu-project/qemu/-/labels

For example in my case I subscribed to receive notifications
only from these labels:

- kind:Bug
- Storage
- pflash
- Fuzzer
- workflow:Merged


Cool feature, I also subscribed to some labels.

I was trying to assign a label, for example "Storage" to this issue:
https://gitlab.com/qemu-project/qemu/-/issues/96

but I can't, should I have some special permission/role?


Yes, you need to be at least a "Reporter" in the members list of a project 
to be able to add labels. You can ask one of the owners (see 
https://gitlab.com/qemu-project/qemu/-/project_members) to add you as a 
reporter.


 Thomas

Switching to the GitLab bug tracker

[Thomas Huth]

 Hi everybody!

As you might have already noticed by some other mails on the qemu-devel 
mailing list, we are in progress of switching our bug tracking tool from 
Launchpad to Gitlab. The new tracker can now be found here:


 https://gitlab.com/qemu-project/qemu/-/issues

Please note that this has some implications:

1) We likely won't have the possibility anymore to automatically send e-mail 
notifications for new bugs to the qemu-devel mailing list. If you want to 
get informed about new bugs, please use the notification mechanism from 
Gitlab instead. That means, log into your gitlab account, browse to


 https://gitlab.com/qemu-project/qemu

and click on the bell icon at the top of the page to manage your 
notifications, e.g. enable notifications for "New issues" there.


2) It should be possible for everybody who has a Gitlab account to open new 
bugs. If you are a maintainer of one of the QEMU subsystems, you might want 
to help with changing certain aspects of bug tickets, too, e.g. add labels 
or assign a ticket to you or somebody else. In that case you need to be 
listed as a "Reporter" in the QEMU project, so please then get in touch with 
one of the "Owners" of the project (see 
https://gitlab.com/qemu-project/qemu/-/project_members ) and ask them to add 
you as a "Reporter".


3) Gitlab has a nice mechanism for closing bugs automatically once the fix 
gets merged to the master branch. To use this feature, please mark your 
commit messages with a "Resolves: " line. See:


https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically

4) I'm in progress of automatically migrating the open bug tickets from 
Launchpad to the Gitlab tracker. If you're interested, please keep an eye on 
those tickets and tell me if you spot any oddity there - the script that I'm 
using for the migration might not be perfect yet.


 Thomas

Re: x86 -> x86 translation

[Thomas Huth]

On 19/04/2021 16.23, Amir Naseredini wrote:

Interesting. But is the `KVM` running an `id` function or is the translation 
just quite similar to the original code (but not certainly the same)?


Well, KVM is (mostly) not translating the code at all, but running the guest 
code in a "virtual machine" on the host CPU. Only some few opcodes and 
things like I/O accesses have to be emulated in that case.


 Thomas

Re: x86 -> x86 translation

[Thomas Huth]

On 19/04/2021 12.34, Amir Naseredini wrote:

Hi,

Quick question. Is the x86 -> x86 in QEMU an `id` function?


 Hi,

the "normal" emulation in QEMU (called TCG - tiny code generator) is 
certainly not an identical translation. If you want to run the original code 
as close as possible to 1:1 "translation", then you have to use the KVM 
accelerator (i.e. use the "-accel kvm" option).


 Thomas

Re: virsh capabilities does not include qemu or kvm

[Thomas Huth]

On 22/03/2021 05.57, shafnamol N wrote:

Hi,
I am new  to Libvirt and Qemu.I have installed Libvirt 7.1.0 and qemu-kvm 4.2.0.
I configured and built libvirt based on instructions from
https://libvirt.org/compiling.html .
But when i tried to create a VM using virsh it shows the following error:
# virsh create /home/abc.xml
error: Failed to create domain from /home/abc.xml
error: invalid argument: could not find capabilities for arch=x86_64 
domaintype=kvm


When i check the hypervisor capabilities ,it doest show qemu or kvm in guest 
domain type.


Try to run "virt-host-validate" ... maybe that helps to identify the problem.

 Thomas

Re: I can't use virtio-gpu-device

[Thomas Huth]

On 17/03/2021 20.16, مجهول الهوية wrote:

I'm write this:
qemu-system-x86_64 -device virtio-gpu-device -L "D:\Program Files\qemu"

and this is result:
D:\Program Files\qemu\qemu-system-x86_64.exe: -device virtio-gpu-device: No 
'virtio-bus' bus found for device 'virtio-gpu-device'


On x86, you should use the "-pci" flavour of the device with the default 
machine instead, i.e. use "virtio-gpu-pci" instead of "virtio-gpu-device".
("virtio-gpu-device" is for machines that use the so-called virtio-mmio 
method for virtio devices, e.g. the "microvm" machine).


 Thomas

Re: -drive syntax

[Thomas Huth]

On 16/10/2020 02.12, Kevin Shell wrote:
> On Thu, Oct 15, 2020 at 09:58:02AM +0200, Max Reitz wrote:
[...]
> So, creating a drive object is a two step process for qemu,
> if={ide, scsi, sd, mtd, floppy, pflash, virtio} is just a shortcut?

Right.

> exp.
> first step is to define the drive object with
> -drive file=FILE,id=ID,if=none
> 
> second step is to attach the drive object to the device backend
> -device {ide, scsi, sd, mtd, floppy, pflash, virtio DEVICE},drive=ID
> 
> Is my understanding right here?

Right again.

It's quite confusing at the beginning, but once you're used to it, this
split configuration is more logical and allows more flexibility. Since it is
confusing in the beginning, I once even gave a presentation about this for
QEMU newcomers:

 https://archive.fosdem.org/2018/schedule/event/vai_qemu_jungle/

 HTH,
  Thomas

Re: Bug https://bugs.launchpad.net/qemu/+bug/1618301 - any hint/workaround?

[Thomas Huth]

On 03/10/2020 20.05, Kamil Jońca wrote:


I have some ancient archive machines in virtualbox. These mainly NT 4.0.
I want to try migrate them to quemu, but without success - cannot make
mouse to work properly. Seems  that I am hit by
https://bugs.launchpad.net/qemu/+bug/1618301.

Does anybody has any hints/workarounds, or this case is hopeless?


Have you tried to use "-device usb-mouse" instead? ... maybe that behaves 
differently...


 Thomas

Re: QEMU 5.1: Can we require each new device/machine to provided a test?

[Thomas Huth]

On 20/05/2020 01.06, John Snow wrote:
> 
> 
> On 5/19/20 5:04 AM, Daniel P. Berrangé wrote:
>> On Mon, May 18, 2020 at 03:56:36PM -0400, John Snow wrote:
>>>
>>>
>>> On 5/15/20 6:23 AM, Daniel P. Berrangé wrote:
>>>> On Fri, May 15, 2020 at 12:11:17PM +0200, Thomas Huth wrote:
>>>>> On 07/04/2020 12.59, Philippe Mathieu-Daudé wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Following Markus thread on deprecating unmaintained (untested) code
>>>>>> (machines) [1] and the effort done to gather the information shared in
>>>>>> the replies [2], and the various acceptance tests added, is it
>>>>>> feasible to require for the next release that each new device/machine
>>>>>> is provided a test covering it?
>>>>>>
>>>>>> If no, what is missing?
>>>>>
>>>>> If a qtest is feasible, yes, I think we should require one for new
>>>>> devices. But what about machines - you normally need a test image for
>>>>> this. In that case, there is still the question where testing images
>>>>> could be hosted. Not every developer has a web space where they could
>>>>> put their test images onto. And what about images that contain non-free
>>>>> code?
>>>>
>>>> Yep, it isn't feasible to make this a hard rule.
>>>>
>>>> IMHO this is where a support tier classification comes into play
>>>>
>>>>  - Tier 1: actively maintained, qtest coverage available. Expected
>>>>to work reliably at all times since every commit is CI
>>>>   tested
>>>>
>>>>   - Tier 2: actively maintained, no qtest coverage. Should usually
>>>>work but regression may creep in due to reliance on the
>>>>   maintainer to manually test on adhoc basis
>>>>
>>>>   - Tier 3: not actively maintained, unknown state but liable to
>>>> be broken indefinitely
>>>>
>>>> Tier 1 is obviously the most desirable state we would like everthing to
>>>> be at. Contributors will have to fix problems their patches cause as
>>>> they will be blocked by CI.
>>>>
>>>> Tier 2 is an admission that reality gets in the way. Ideally stuff in
>>>> this tier will graduate to Tier 1 at some point. Even if it doesn't
>>>> though, it is still valid to keep it in QEMU long term. Contributors
>>>> shouldn't gratuitously break stuff in these board, but if they do,
>>>> then the maintainer is ultimately responsible for fixing it, as the
>>>> contributors don't have a test rig for it.
>>>>
>>>> Tier 3 is abandonware. If a maintainer doesn't appear, users should
>>>> not expect it to continue to exist long term. Contributors are free
>>>> to send patches which break this, and are under no obligation to
>>>> fix problems in these boards. We may deprecate & delete it after a
>>>> while
>>>>
>>>>
>>>> Over time we'll likely add more criteria to stuff in Tier 1. This
>>>> could lead to some things dropping from Tier 1 to Tier 2. This is
>>>> OK, as it doesn't make those things worse than they already were.
>>>> We're just saying that Tier 2 isn't as thoroughly tested as we
>>>> would like it to be in an ideal world.
>>>
>>> I really like the idea of device support tiers codified directly in the
>>> QEMU codebase, to give upstream users some idea of which devices we
>>> expect to work and which we ... don't, really.
>>>
>>> Not every last device we offer is enterprise production ready, but we
>>> don't necessarily do a good job of explaining which devices fall into
>>> which categories, and we've got quite a few of them.
>>>
>>> I wonder if a 2.5th tier would be useful; something like a "hobbyist"
>>> tier for pet project SoC boards and the like -- they're not abandoned,
>>> but we also don't expect them to work, exactly.
>>>
>>> Mild semantic difference from Tier 3.
>>
>> I guess I was thinking such hobbyist stuff would fall into tier 2  if the
>> hobbyist maintainer actually responds to fixing stuff, or tier 3 if they
>> largely aren't active on the mailing list responding to issues/questions.
>>
>> We add have a 4 tier system overall and put hobbyist stuff at tier 3,
>> and abandonware at tier 4.
>>
>

Re: QEMU 5.1: Can we require each new device/machine to provided a test?

[Thomas Huth]

On 07/04/2020 12.59, Philippe Mathieu-Daudé wrote:
> Hello,
> 
> Following Markus thread on deprecating unmaintained (untested) code
> (machines) [1] and the effort done to gather the information shared in
> the replies [2], and the various acceptance tests added, is it
> feasible to require for the next release that each new device/machine
> is provided a test covering it?
> 
> If no, what is missing?

If a qtest is feasible, yes, I think we should require one for new
devices. But what about machines - you normally need a test image for
this. In that case, there is still the question where testing images
could be hosted. Not every developer has a web space where they could
put their test images onto. And what about images that contain non-free
code?

 Thomas

Re: [RFC PATCH] configure: deprecate 32 bit build hosts

[Thomas Huth]

On 26/09/2019 15.46, Christian Borntraeger wrote:
> 
> 
> On 26.09.19 14:58, Daniel P. Berrangé wrote:
>> On Thu, Sep 26, 2019 at 08:50:36AM +0100, Peter Maydell wrote:
>>> On Thu, 26 Sep 2019 at 00:31, Alex Bennée  wrote:

 The 32 bit hosts are already a second class citizen especially with
 support for running 64 bit guests under TCG. We are also limited by
 testing as actual working 32 bit machines are getting quite rare in
 developers personal menageries. For TCG supporting newer types like
 Int128 is a lot harder with 32 bit calling conventions compared to
 their larger bit sized cousins. Fundamentally address space is the
 most useful thing for the translator to have even for a 32 bit guest a
 32 bit host is quite constrained.

 As far as I'm aware 32 bit KVM users are even less numerous. Even
 ILP32 doesn't make much sense given the address space QEMU needs to
 manage.
>>>
>>> For KVM we should wait until the kernel chooses to drop support,
>>> I think.
>>
>> What if the kernel is waiting for QEMU to drop support too ;-P
> 
> For what its worth on kvm/s390 we never cared about implementing
> 32 bit. 

Looking at tcg/s390/tcg-target.inc.c :

...
/* We only support generating code for 64-bit mode.  */
#if TCG_TARGET_REG_BITS != 64
#error "unsupported code generation mode"
#endif
...

... it seems to me that TCG does not support 32-bit on s390 either. I
think we can remove s390 (32-bit) from the list completely?

 Thomas

Re: [RFC PATCH] configure: deprecate 32 bit build hosts

[Thomas Huth]

On 26/09/2019 01.30, Alex Bennée wrote:
> The 32 bit hosts are already a second class citizen especially with
> support for running 64 bit guests under TCG. We are also limited by
> testing as actual working 32 bit machines are getting quite rare in
> developers personal menageries. For TCG supporting newer types like
> Int128 is a lot harder with 32 bit calling conventions compared to
> their larger bit sized cousins. Fundamentally address space is the
> most useful thing for the translator to have even for a 32 bit guest a
> 32 bit host is quite constrained.
> 
> As far as I'm aware 32 bit KVM users are even less numerous. Even
> ILP32 doesn't make much sense given the address space QEMU needs to
> manage.
> 
> Lets mark these machines as deprecated so we can have the wailing and
> gnashing of teeth now and look to actually dropping the support in a
> couple of cycles.
>
> Signed-off-by: Alex Bennée 
> Cc: Richard Henderson 
> ---
>  configure | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/configure b/configure
> index 542f6aea3f..776fd460b5 100755
> --- a/configure
> +++ b/configure
> @@ -728,7 +728,7 @@ ARCH=
>  # Normalise host CPU name and set ARCH.
>  # Note that this case should only have supported host CPUs, not guests.
>  case "$cpu" in
> -  ppc|ppc64|s390|s390x|sparc64|x32|riscv32|riscv64)
> +  ppc64|s390|s390x|sparc64|riscv64)

I think you can also remove "s390". "s390" is the 32-bit variant,
"s390x" is the 64-bit variant.

>  supported_cpu="yes"
>;;
>ppc64le)
> @@ -737,7 +737,6 @@ case "$cpu" in
>;;
>i386|i486|i586|i686|i86pc|BePC)
>  cpu="i386"
> -supported_cpu="yes"
>;;
>x86_64|amd64)
>  cpu="x86_64"
> @@ -745,19 +744,22 @@ case "$cpu" in
>;;
>armv*b|armv*l|arm)
>  cpu="arm"
> -supported_cpu="yes"
>;;
>aarch64)
>  cpu="aarch64"
>  supported_cpu="yes"
>;;
> -  mips*)
> +  mips64*)
>  cpu="mips"
>  supported_cpu="yes"
>;;
> +  mips*)
> +cpu="mips"
> +  ;;
>sparc|sun4[cdmuv])
>  cpu="sparc"
> -supported_cpu="yes"
> +  ;;
> +  x32|riscv32)

You forgot to add "ppc" (and "s390") here.

>;;
>*)
>  # This will result in either an error or falling back to TCI later
> @@ -6438,12 +6440,12 @@ if test "$supported_cpu" = "no"; then
>  echo "WARNING: SUPPORT FOR THIS HOST CPU WILL GO AWAY IN FUTURE 
> RELEASES!"
>  echo
>  echo "CPU host architecture $cpu support is not currently maintained."
> -echo "The QEMU project intends to remove support for this host CPU in"
> -echo "a future release if nobody volunteers to maintain it and to"
> -echo "provide a build host for our continuous integration setup."
> -echo "configure has succeeded and you can continue to build, but"
> -echo "if you care about QEMU on this platform you should contact"
> -echo "us upstream at qemu-de...@nongnu.org."
> +echo "The QEMU project intends to remove support for all 32 bit host"
> +echo "CPUs in a future release. 64 bit hosts will need a volunteer"
> +echo "to maintain it and to provide a build host for our continuous"
> +echo "integration setup. configure has succeeded and you can continue"
> +echo "to build, but if you care about QEMU on this platform you"
> +echo "should contact us upstream at qemu-de...@nongnu.org."
>  fi
>  
>  if test "$supported_os" = "no"; then

In case this gets accepted, we also might want to deprecate the
qemu-system-i386, qemu-system-arm and qemu-system-ppc targets, since
they are AFAIK just a subset of qemu-system-x86_64, qemu-system-aarch64
and qemu-system-ppc64. But that's likely something for a later patch, I
think.

 Thomas

Re: [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282

[Thomas Huth]

On 2019-01-30 17:59, Alessandro Carminati wrote:
> From: Thomas Huth 
[...]
> Thank you for your explanation. It helps me a lot in comprehending how Qemu 
> works, and also understand some of the behavior I see in the logs.
> Using GDB was my first choice, I tried this way before the log. It is 
> supposed to be interactive, therefore more comfortable than  reading a giga 
> log. But when I tried it, on the m68k architecture, I couldn't make it work. 
> To say it better, I was able to set breakpoints and start the execution, but 
> the single step didn't work in my case. In the past, I used Qemu-GDB solution 
> with ARM architecture with no problem, so I assumed I just stepped into m68k  
> implementation problem and switched on the backup solution. Is there anything 
> else I should know on the  "target remote" GDB "s" and "si" commands to work 
> on the m68k implementation? When I issue the command, the GDB interface 
> reports no error, but the target CPU state does not change.

That rings a bell, I think this is the problem that has been reported to
the qemu-devel mailing list some days ago:

 https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06241.html

The problem has been introduced with QEMU v3.0 ... so as long as it is
not fixed yet, maybe you could try v2.12 to see whether single-stepping
works there for you?

 Thomas

Re: [Qemu-discuss] Weird qemu behaviour with Freescale Coldfire MCF5282

[Thomas Huth]

On 2019-01-30 16:26, Alessandro Carminati wrote:
> Hello,
> 
> I'm trying reverse engineer the firmware, apparently bare metal, of an 
> industrial controller. The device is based on a Coldfire controller, to be 
> more precise, the MCF5282. To track its behavior, I want to use Qemu in its 
> M68k fashion which is supporting already the MCF5206 and the MCF5208. The 
> Coldfire implementation of Qemu lacks in many places, and it seems targeted 
> to run Linux after the bootloader has left the hardware in a particular 
> state. To run my firmware, I had to patch it removing all the hardware 
> initialization, and write a new Qemu file for the CPU I wanted to target, the 
> MCF5282.
> 
> So far, It seems that my code is working, and the CPU is initialized as the 
> initialization code I have skipped would have done. When I start my 
> emulation, strangeness begins, and there I ask for your help for 
> understanding what is going on. When I run
> 
> qemu-system-m68k -nographic -cpu m5282 -kernel Firmware.bin.qemuPatched \
> -serial telnet:127.0.0.1:,server,nowait \
> -serial telnet:127.0.0.1:4445,server,nowait \
> -serial telnet:127.0.0.1:4446,server,nowait \
> -d in_asm -D execution.log
> 
> 
> I expected all the instruction of the target CPU to be logged, and that's it 
> is what's happened, at least until it reaches a branch instruction.
> That time forward, no more instructions are logged, though the emulation is 
> continuing.
> 
> I can say that emulation is continuing because if I add to the logged 
> properties the target machine status, I see that the CPU state is changing 
> after the that last instruction is logged and the PC is changing also.
> The strangeness does not stop here, and if I follow the PC values, I see that 
> CPU is executing instructions in the firmware address space in an unexpected 
> way, to make a long story short, it seems it is sampling the real flow 
> without writing every single step.
> 
> Does someone recognize in it the expected behavior?

Sure. It's as simple as this: QEMU is a just-in-time emulator, that
means that the all new code that is seen by the m68k CPU is translated
to host CPU machine code. For code blocks that have already been
translated, the target m68k code is not considered again. So if your
code branches to a part that has already been executed once, you won't
see it again in the output of "-d in_asm".
If you need single-stepping, I recommend to attach a remote GDB instead.

 HTH,
  Thomas

Re: [Qemu-discuss] From -usbdevice host: to -device usb-host,

[Thomas Huth]

On 2018-12-27 08:35, Narcis Garcia wrote:
> In environments with Qemu 2.8.1 I use:
> qemu... -usbdevice host:046d:08b2
> 
> In environments with newer versions... Should I specify with this syntax?
> qemu... -device usb-host,046d:08b2
> (comma and vendor:product)

Hi, please have a look at the QEMU documentation:

https://qemu.weilnetz.de/doc/qemu-doc.html#usb_005fdevices

 Thomas

Re: [Qemu-discuss] Any easy war to access cpu.h in vl.c

[Thomas Huth]

On 2018-12-04 15:46, ZEESHAN HAYAT wrote:
> Hi,
> I am trying to access target/nios2/cpu.h in vl.c. If I add #include 
> "target/nios2/cpu.h" in vl.c, I get the following errors:

You can not include a target-specific header file in common code. vl.c
is only compiled once for all targets, but target-specific header files
like cpu.h contain target-specific #defines like TARGET_LONG_BITS - so
if you'd use one of these defines in common code, it would be right for
one target but wrong for the other.

If you need to use cpu.h from the target directory, add your code to a
target specific file instead. Look for "obj-y" in the Makefiles instead
of "common-obj-y".

 HTH,
  Thomas

[Qemu-discuss] QEMU advent calendar 2018

[Thomas Huth]

 Hi everybody!

Starting today, on December 1st, the first door of the QEMU Advent
Calendar 2018 can now be opened! The advent calendar reveals a new disk
image for download on each of the first 24 days in December 2018, to
create a fun experience for the QEMU community, to celebrate the
15th anniversary of QEMU, and to provide some good images for testing
the various CPU targets of QEMU: This year it will contain way more
images for non-x86 targets than before, so if you are interested
in collecting test images for the various CPU targets of QEMU, be sure
to check the calendar regularly:

 https://www.qemu-advent-calendar.org/2018/

And by the way, more disk images are still required to complete the run
this year, so if you are interested in contributing, please have a look
at my original announcement here:

 https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg02388.html

  Enjoy the calendar,
   Thomas

Re: [Qemu-discuss] Debugging QEMU NIOS2

[Thomas Huth]

On 2018-11-21 11:24, Zeeshan Hayat wrote:
> Hi,
> 
> 
> I am trying to debug simple program (hello_world). I run the QEMU as,
> 
> 
>>  qemu-system-nios2 -s
> 
> 
> and run the nios aware gdb as,
> 
> 
>> nios2-elf-gdb hello
> 
> 
> and than in gdb I attach it to QEMU by,
> 
> 
>> target remote localhost:1234
> 
> 
> but when I type "continue" in gdb window, it just hangs and prints nothing. I 
>  tried to set breakpoint but still the same issue
> 
> 
> hello executable is generated as,
> 
> 
>> nios2-elf-gcc -g -o hello hello.c
> 
> 
> Where hello.c is a simple program which prints "hello world"
> 
> 
> I am not sure if I am doing something wrong here...

As Peter already mentioned in his mail yesterday, you're using the wrong
QEMU binary: qemu-system-nios2 emulates a full system, so this is e.g.
for running a Linux kernel. You're apparently trying to run a normal
user-space program, so you have to use "qemu-nios2" instead.

 HTH,
  Thomas

Re: [Qemu-discuss] Error Buidling QEMU

[Thomas Huth]

On 2018-11-18 21:05, Zeeshan Hayat wrote:
> Hi,
> 
> 
> 
> I am trying to build QEMU. I get the following errors while build.
> 
> 
> /home/user/QEMU/qemu/block/file-posix.c:1979: error: unknown field 'prealloc' 
> specified in initializer
> /home/user/QEMU/qemu/block/file-posix.c:1980: error: unknown field 'errp' 
> specified in initializer
> 
> Could you please tell me how can I solve it?

 Hi!

Please provide some more information: Where did you download the sources
from / which version of QEMU are you using? How did you configure it?
What host system are you using? Which version of GCC are you using?

  Thomas

[Qemu-discuss] QEMU Advent Calendar 2018 - Help wanted

[Thomas Huth]

 Hi all!

This year, we are celebrating the 15th anniversary of QEMU [1] - to do
so, we would like to perform another edition of the QEMU Advent Calendar.

If you didn't see the previous QEMU Advent Calendars yet, please visit
the website and have a look at the editions from 2014 and 2016 (which
can be selected in the menu at the top):

  https://www.qemu-advent-calendar.org/

This year, too, the QEMU Advent Calendar 2018 will be a website that
reveals a new disk image for download each day in December until the
holiday season starts. Launching the disk image under QEMU will bring up
a nice surprise!

But to be able to make this happen, we need help from people who
- have ideas for disk images
- would like to prepare one or more disk images.
Ideally, you have an idea for a disk image and also prepare it yourself.
But we also are glad to get just the ideas, or help from people who
would like to prepare a disk image with the idea from somebody else!

Possible ideas (others are welcome of course, too):
- Showcase a new feature that has been added to QEMU recently
- Package your favorite freeware DOS game from your childhood
  (must be freely redistributable, so e.g. use FreeDOS as OS)
- Know a fancy new or old freely available Operating System which
  we did not feature in the previous advent calendars yet?
- Any cool self-made firmware or extensions to existing firmware
  that runs in QEMU.
- It would also be great to get some more images for non-x86 targets,
  so if you know something usable, please speak up!

Disk image requirements:
 * We need 24 disk images (for the first 24 days of December)
 * Content must be freely redistributable (i.e. no proprietary
   license that prevents distribution). For GPL based software,
   you need to provide the source code, too.
 * Provide a name and a short description of the disk image
   (e.g. with hints on what to try)
 * Provide a ./run shell script that prints out the name and
   description/hints and launches QEMU
 * Provide a screenshot/image/logo for the website
   (preferred resolution of the image is 320x240)
 * Size should be ideally under 100 MB per disk image
   (but if some few images are bigger, that should be OK, too)

Are you interested in participating? Then please reply to this email
(off-list if you do not want to spoil your idea for disk images).

Or do you have questions? Then feel free to reply or ask on the #qemu
channel on irc.oftc.net, too.

 Thomas


PS: The QEMU Advent Calendar 2018 is a secular calendar (not
religious). The idea is to create a fun experience for the QEMU
community which can be shared with everyone, and to celebrate the 15th
anniversary of QEMU. You don't need to celebrate Christmas or another
religious festival to participate!

[1] According to the following mail, QEMU 0.1 was announced in March
2003: https://www.winehq.org/pipermail/wine-devel/2003-March/015577.html

Re: [Qemu-discuss] console output with -nographic on Windows

[Thomas Huth]

On 2018-09-17 13:26, Brendan Simon (eTRIX) wrote:
> I've been trying to use the following GNU MCU Eclipse QEMU releases to
> do unit tests for ARM Cortex binaries.
> 
> https://gnu-mcu-eclipse.github.io/qemu/
> https://gnu-mcu-eclipse.github.io/qemu/releases/
> 
> I compiled the very simple semi-hosting hello world sample in the gcc
> arm installation (from ARM download site).  It's a basic `printf("Hello
> world!");`
> 
> It runs ok on the Mac.  i.e. displays "Hello world!" on the terminal
> that I run qemu from.
> 
> However the same command line and exact same binary does not show any
> output when run on a Windows box (Win 10).  I tried from MSYS2 bash
> shell and Windows Command Prompt, and both show no output.
> 
> A bit of googling suggests that it displaying console output just
> doesn't work on Windows.
> 
> Is that really true?  Why can't Windows output to stdout?  Surely it's
> technically possible, and not too difficult?  Surely there must be a way
> to get stdout working Windows.
> 
> What magic do I have to do to get this working?

Is your QEMU binary using SDL1.2 ? In that case, it's likely that SDL
redirects stdout into a file. Try a binary that is linked against SDL2
instead - as far as I know, SDL2 does not do this redirecation anymore.

 Thomas

Re: [Qemu-discuss] unstable qemu under Ubuntu (on Windows)

[Thomas Huth]

On 2018-09-05 10:15, Fabrizio Caruso wrote:
[...]
> Should I try a real virtual enviroment, e.g., VirtualBox? Does qemu run under 
> VirtualBox?

I don't know VirtualBox, but you can certainly run QEMU on a Linux that
runs within QEMU on Windows:

https://www.qemu.org/2017/11/22/haxm-usage-windows/

 HTH,
  Thomas

Re: [Qemu-discuss] Request for information inclusion on the wiki links page section of QEMU project!

[Thomas Huth]

On 08/15/2018 04:22 PM, daniel silva ferreira bruno wrote:
> Hi, staff of QEMU project!
> I am Daniel Silva Ferreira Bruno, creator of the JavaQEMU Open Source 
> Software, available at:https://sourceforge.net/projects/javaqemu/.
> JavaQemu is a Graphical User Interface Front End for QEMU, written in Java 
> Programming Language!
> I would like the JavaQemu project information to be included in the "GUI 
> Front Ends" section of the wiki page of QEMU project, available 
> at:https://wiki.qemu.org/Links, please.

According to that page at Sourceforge, "This project is no longer active
because I stopped playing with Java since a long time" and the last
release is also more than 3 years old. Honestly, I don't think we should
put links to dead projects into the wiki, that's just a bad experience
for the users if they try out a front-end software that likely does not
work with the latest version of QEMU anymore.

Having said that, I think we can remove most of the other GUI entries in
the Wiki nowadays, since they seem to be pretty much out-of-date.

 Thomas

Re: [Qemu-discuss] Does Anyone Know What The x86_64 Magic and Mask Are (For binfmt_misc)?

[Thomas Huth]

On 07/28/2018 06:29 PM, Tom A wrote:
> Hello Everyone,
> 
> Hopefully, I am posting in the right place. I normally don't use a mailing
> list. Anyway, I was wondering if anyone here knows what the magic and mask
> values are for an x86_64 Linux binary file.
> 
> My goal is to run a chroot x86_64 environment on my aarch64 device. I can
> use binfmt_misc to achieve my goal, but I need to know what the magic and
> mask values are so that Linux knows the type of binary files should be
> executed with qemu-x86_64-static.

The magic values are the first bytes of the ELF file that have to match,
and the mask is, well, the mask value that is ANDed with the values from
the ELF file before the comparison is done.

Have a look at one of the various ELF specs, e.g.
http://www.cs.cmu.edu/afs/cs/academic/class/15213-s00/doc/elf.pdf - I
think the value you are looking for is the EI_CLASS field which comes
right after the "\x7fELF" identifier.

> I took a look at the qemu-binfmt-conf.sh
> , but
> it only gives the values for i386 and i486 binary files.

I'm a little bit surprised that we do not have an entry for x86_64 there
yet. Maybe Laurent or Riku know why it is not there yet...

 Thomas

Re: [Qemu-discuss] How to gpg verify qemu-2.12.0.tar.xz?

[Thomas Huth]

On 20.06.2018 08:15, Edward Smith wrote:
> Great, thanks Thomas!
> 
> Apparently I was missing the 0x3353C9CE prefix from my key search. What
> is that exactly?

It's the longer form of the key ID. The 32-bit-only key IDs are not safe
anymore these days, see https://evil32.com/ for details.

> Also, I got this output from verifying with this key:
> 
> gpg: Signature made Tue 24 Apr 2018 12:55:16 PM CDT using RSA key ID
> F108B584
> gpg: Good signature from "Michael Roth  <mailto:fluks...@gmail.com>>"
> gpg: aka "Michael Roth  <mailto:mdr...@utexas.edu>>"
> gpg: aka "Michael Roth  <mailto:mdr...@linux.vnet.ibm.com>>"
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: CEAC C9E1 5534 EBAB B82D  3FA0 3353 C9CE F108 B584
> 
> I take it everything is ok?

AFAIK that simply means that you don't have anybody in your keyring who
you trust and who signed his key. See
https://en.wikipedia.org/wiki/Web_of_trust for the concept of the web of
trust. If that's important to you, I can recommend to visit KVM Forum,
DevConf, FOSDEM or another open source conference where you can meet the
QEMU developers and exchange the key fingerprints with some people there.

 Thomas


> On Wed, Jun 20, 2018 at 12:47 AM Thomas Huth  <mailto:th...@redhat.com>> wrote:
> 
> On 20.06.2018 06:19, Edward Smith wrote:
> > Hello,
> >
> > I downloaded the following files to my Ubuntu machine:
> >
> > Jun 19 22:37 qemu-2.12.0.tar.xz
> > Jun 19 22:37 qemu-2.12.0.tar.xz.sig
> >
> > I then attempted to verify the gpg signature of the
> qemu-2.12.0.tar.xz file
> > and got the following output:
> >
> > gpg: Signature made Tue 24 Apr 2018 12:55:16 PM CDT using RSA key ID
> > F108B584
> > gpg: Can't check signature: public key not found
> >
> > I tried looking for RSA key with the ID F108B584 on the MIT public key
> > server but could not find it.
> >
> > Any ideas?
> 
> It should be available on the MIT server:
> 
> http://pgp.mit.edu/pks/lookup?op=vindex=0x3353C9CEF108B584
> 
>  HTH,
>   Thomas
> 




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-discuss] How to gpg verify qemu-2.12.0.tar.xz?

[Thomas Huth]

On 20.06.2018 06:19, Edward Smith wrote:
> Hello,
> 
> I downloaded the following files to my Ubuntu machine:
> 
> Jun 19 22:37 qemu-2.12.0.tar.xz
> Jun 19 22:37 qemu-2.12.0.tar.xz.sig
> 
> I then attempted to verify the gpg signature of the qemu-2.12.0.tar.xz file
> and got the following output:
> 
> gpg: Signature made Tue 24 Apr 2018 12:55:16 PM CDT using RSA key ID
> F108B584
> gpg: Can't check signature: public key not found
> 
> I tried looking for RSA key with the ID F108B584 on the MIT public key
> server but could not find it.
> 
> Any ideas?

It should be available on the MIT server:

http://pgp.mit.edu/pks/lookup?op=vindex=0x3353C9CEF108B584

 HTH,
  Thomas

Re: [Qemu-discuss] newbie question: how to connect to a running guest with qemu monitor

[Thomas Huth]

On 05.06.2018 17:35, Lentes, Bernd wrote:
> 
> 
> - On May 31, 2018, at 7:47 AM, Han Han h...@redhat.com wrote:
> 
>> virsh qemu-monitor-command is the answer.
>> You can use it by following:
>> For qmp command:
>> # virsh qemu-monitor-command  $VM_NAME $QMP_COMMAND
>> For hmp commmand:
>> # virsh qemu-monitor-command --hmp $VM_NAME $HMP_COMMAND
>>
>> On Thu, May 31, 2018 at 2:28 AM, Jakob Bohm  wrote:
>>
> 
> Hi,
> 
> that's it.
> 
> Example:
> 
> virsh # qemu-monitor-command --hmp mausdb2 info block
> drive-virtio-disk0 (#block118): /var/lib/libvirt/images/mausdb/mausdb.dd (raw)
> Cache mode:   writethrough, direct
> 
> drive-ide0-0-0 (#block371): 
> /mnt/idg-2/SysAdmin_AG_Wurst/software_und_treiber/linux/knoppix/KNOPPIX_V8.1-2017-09-05-DE.iso
>  (raw, read-only)
> Removable device: not locked, tray closed
> Cache mode:   writeback, direct
> 
> 
> That's most of what i need. But isn't it possible to connect with the 
> qemu-monitor/conscole to the GUI of an already running guest ?
> Without vnc which is an extra layer. Do i need to start the guest with 
> special options ?
> 
> "man qemu-kvm" says:
> For instance you could use this to allow a single stdio chardev to be used by 
> two serial ports and the QEMU monitor:
> 
>-chardev stdio,mux=on,id=char0 \
>-mon chardev=char0,mode=readline \
>-serial chardev:char0 \
>-serial chardev:char0
> 
> Isn't that what i need ? How do i connect to char0 ?

So you mean a serial text console, not the graphical console? Assuming
that you're using libvirt here, you could try:

 virsh console guestname

But note that you also need to set the kernel parameter "console=ttyS0"
for this too (e.g. via grub).

 Thomas

Re: [Qemu-discuss] How to run qemu with -nographic and -monitor but still be able to send Ctrl+C to the guest?

[Thomas Huth]

On 10.04.2018 16:06, Ciro Santilli wrote:
> On Tue, Apr 10, 2018 at 6:27 AM, Thomas Huth <th...@redhat.com> wrote:
>> On 10.04.2018 02:10, Ciro Santilli wrote:
>>> On Mon, Apr 9, 2018 at 1:33 PM, Thomas Huth <th...@redhat.com> wrote:
>>>> On 08.04.2018 12:39, Ciro Santilli wrote:
>> [...]
>>>>> Is there a way to both keep my `Ctrl-C` and `-monitor` working with
>>>>> `-nographic`?
>>>>>
>>>>> Full QEMU command:
>>>>>
>>>>> qemu-system-x86_64 -append 'root=/dev/vda console=ttyS0' -kernel
>>>>> 'bzImage' -drive file='rootfs.ext2.qcow2,if=virtio,format=qcow2'
>>>>> -nographic -monitor telnet::45454,server,nowait
>>>>
>>>> I think you need a chardev with signal=off for that. Try something like:
>>>>
>>>> qemu-system-x86_64  -nographic -monitor telnet::45454,server,nowait \
>>>>   -chardev stdio,id=s1,signal=off \
>>>>   -serial none -device isa-serial,chardev=s1
>>>>
>>>
>>> I tried that and Ctrl+C does get passed to the guest as I wanted.
>>>
>>> However, when I do this, I noticed that I can't pass Ctrl+A X to
>>> easily quit QEMU (I know I can do quit on the monitor).
>>>
>>> Is there a way to also keep Ctrl+A X working, in addition to having
>>> Ctrl+C passed to the guest?
>>
>> Yes, you need to multiplex the stdio output with a HMP monitor:
>>
>> qemu-system-x86_64  -nographic -monitor telnet::45454,server,nowait \
>>  -chardev stdio,id=s1,signal=off,mux=on -serial none \
>>  -device isa-serial,chardev=s1 -mon chardev=s1,mode=readline
>>
> 
> Thanks, that worked perfectly!
> 
> Do you know how to do the same thing for `qemu-system-arm -M
> versatilepb` or `qemu-system-aarch64 -M virt`?

Not sure ... at least versatilepb seems to use an embedded UART, so
-device likely does not work there.

But you could try to simply use "-serial mon:stdio" here. Actually, now
that I remembered that option ... that might even also work on x86
instead of all that complicated stuff that I told you before:

qemu-system-x86_64 -nographic -monitor telnet::45454,server,nowait \
   -serial mon:stdio

(I initially didn't know that you also wanted to have a HMP monitor /
Ctrl-A X here, too, that's why I did not think of this solution in my
first mail)

 HTH,
  Thomas

Re: [Qemu-discuss] How to run qemu with -nographic and -monitor but still be able to send Ctrl+C to the guest?

[Thomas Huth]

On 10.04.2018 02:10, Ciro Santilli wrote:
> On Mon, Apr 9, 2018 at 1:33 PM, Thomas Huth <th...@redhat.com> wrote:
>> On 08.04.2018 12:39, Ciro Santilli wrote:
[...]
>>> Is there a way to both keep my `Ctrl-C` and `-monitor` working with
>>> `-nographic`?
>>>
>>> Full QEMU command:
>>>
>>> qemu-system-x86_64 -append 'root=/dev/vda console=ttyS0' -kernel
>>> 'bzImage' -drive file='rootfs.ext2.qcow2,if=virtio,format=qcow2'
>>> -nographic -monitor telnet::45454,server,nowait
>>
>> I think you need a chardev with signal=off for that. Try something like:
>>
>> qemu-system-x86_64  -nographic -monitor telnet::45454,server,nowait \
>>   -chardev stdio,id=s1,signal=off \
>>   -serial none -device isa-serial,chardev=s1
>>
> 
> I tried that and Ctrl+C does get passed to the guest as I wanted.
> 
> However, when I do this, I noticed that I can't pass Ctrl+A X to
> easily quit QEMU (I know I can do quit on the monitor).
> 
> Is there a way to also keep Ctrl+A X working, in addition to having
> Ctrl+C passed to the guest?

Yes, you need to multiplex the stdio output with a HMP monitor:

qemu-system-x86_64  -nographic -monitor telnet::45454,server,nowait \
 -chardev stdio,id=s1,signal=off,mux=on -serial none \
 -device isa-serial,chardev=s1 -mon chardev=s1,mode=readline

  Thomas

Re: [Qemu-discuss] How to run qemu with -nographic and -monitor but still be able to send Ctrl+C to the guest?

[Thomas Huth]

On 08.04.2018 12:39, Ciro Santilli wrote:
> https://stackoverflow.com/questions/49716931/how-to-run-qemu-with-nographic-and-monitor-but-still-be-able-to-send-ctrlc-to
> 
> I have just found out that if you run QEMU with `-monitor
> telnet::45454,server,nowait -nographic`, then Ctrl-C kills the QEMU VM
> instead of generating SIGINT on the guest:
> https://unix.stackexchange.com/questions/167165/how-to-pass-ctrl-c-to-the-guest-when-running-qemu-with-nographic/436321#436321
> 
> However, I don't want to remove `-monitor` because it is convenient to
> automate monitor commands, e.g. it allows me to create a helper script
> that does:
> 
> echo 'savevm my_snap_id' |  telnet localhost 45454
> 
> Is there a way to both keep my `Ctrl-C` and `-monitor` working with
> `-nographic`?
> 
> Full QEMU command:
> 
> qemu-system-x86_64 -append 'root=/dev/vda console=ttyS0' -kernel
> 'bzImage' -drive file='rootfs.ext2.qcow2,if=virtio,format=qcow2'
> -nographic -monitor telnet::45454,server,nowait

I think you need a chardev with signal=off for that. Try something like:

qemu-system-x86_64  -nographic -monitor telnet::45454,server,nowait \
  -chardev stdio,id=s1,signal=off \
  -serial none -device isa-serial,chardev=s1

 HTH,
  Thomas

Re: [Qemu-discuss] How to boot from D (not cdrom)?

[Thomas Huth]

On 06.04.2018 20:41, Narcis Garcia wrote:
> I know the "-boot d" parameter for Qemu, but it only works when optical
> media is declared.
> If I boot a virtual machine with primary and secondary disk imatges
> (e.g. disk1.img and disk2.img in this order), how can I force Qemu
> (included BIOS) to boot from second disk?
> 
> Example scenario: disk1.img is a formatted hard disk image, and
> disk2.img is an image (dd) from USB installer stick.

With certain firmware implementations, you can use the bootindex
property, e.g.:

 qemu-system-... -drive if=none,id=dr1,file=... \
-device usb-storage,bootindex=1,drive=dr1,...

 HTH,
  Thomas

Re: [Qemu-discuss] Adding an additional console to the VM on x86

[Thomas Huth]

On 16.02.2018 04:45, Jintack Lim wrote:
> Hi,
> 
> I was able to add an additional console to the VM on ARM like this,
> 
> -chardev socket,server,host=*,nowait,port=,telnet,id=mychardev0
> -device virtio-serial-device
> -device virtconsole,chardev=mychardev0
> 
> But the same command gave an error on x86.
> 
> qemu-system-x86_64: -device virtio-serial-device: No 'virtio-bus' bus
> found for device 'virtio-serial-device'
> 
> I wonder what would be the correct option to do that on x86?

AFAIK the "-device virtio-*-device" only works on ARM (with
virtio-mmio). On x86 and other platforms, please try to use "-device
virtio-serial-pci" instead, since x86 uses the virtio-pci transport.

 Thomas

Re: [Qemu-discuss] qemu-system-sparc and network devices

[Thomas Huth]

On 03.02.2018 23:30, Scott Harris wrote:
> Hi
> 
> The qemu-system-sparc has a 'lance' model NIC built in and so doesn't
> require adding it as a device to the configuration. For my application
> that involves getting Sparcstation2 software to run on a Linux PC, the
> command line looks something like :
> 
> qemu-system-sparc -M "SS-5" -m 256\
>  -nographic -parallel vc\
>  -name "Netbsd 5"\
>  -drive "file=Boot.qcow2,index=0,media=disk"\
>  -boot order=cd,menu=off\
>  -net nic,vlan=0,model=lance,macaddr=DE:AD:BE:EF:F3:E5\
>  -net tap,vlan=0,ifname=tap0,script=no,downscript=no\
>  -localtime
> 
> 
> This setup works fine for my purposes but the '-net' option is
> deprecated. I personally would like to avoid the deprecated options but
> I can't actually get the recommended '-netdev' option to work properly
> with qemu-system-sparc.
Try something like:

 -netdev tap,id=nd1,...
 -net nic,netdev=nd1,...

 Thomas

Re: [Qemu-discuss] how to disable DHCP client on qemu

[Thomas Huth]

On 27.01.2018 00:42, Medi Montaseri wrote:
> I don't think we are using libvert...here is the actual call to
> runqemu(1) and sub-sequent call to qemu-system-x86_64.

To be sure, what do you get when you run for example "lsof -iudp" or
check the running processes with "ps aux" ? Do you see any dnsmasq or
dhcpd running?

[...]
>  -net nic,model=virtio,macaddr=52:54:00:12:34:124 -net
> tap,ifname=tap0,script=no,downscript=no
>  -net nic,model=virtio,macaddr=52:54:00:12:34:125 -net
> tap,ifname=tap1,script=no,downscript=no

AFAIK that configures two interfaces on the same hub ("vlan") ... not
sure this is really intended here? If not, you should either use the
"vlan=X" parameter, or use "-netdev" instead.

>  -append "vga=0 uvesafb.mode_option=640x480-32 root=/dev/vda rw
> mem=256M ip=off oprofile.timer=1 rootfstype=ext4 console=ttyS0"
> 
> Note how I have set "ip=off" (similar to ip=none) and I am expecting
> qemu to stay off of network configuration, I'll do it later in my boot
> scripts

That content of the -append parameter is for the guest kernel only, so
QEMU itself certainly does not care about that "ip=off".

 Thomas

Re: [Qemu-discuss] No IP in net interface when using socket netdev

[Thomas Huth]

On 24.01.2018 16:09, Zihan Yang wrote:
> Hi,
> 
> Thanks for the help, but I don't see how I can assign a static IP to it in
> the command line, neither the '-netdev socket' option or the '-device
> e1000e' option allows a ip property.

Assigning the IP address to an interface is job of the OS that uses the
interface, so you've got to do this in the guest.

> I tried to manually assign one inside
> guest VM, but it seems not working, I still can't ping each other, they are
> in the same subnet.

If that does not work, you could try to use a network sniffer like
tcpdump or wireshark in one of the guests to verify whether the packets
get through at all or not. Or try the network sniffing feature of QEMU
to see whether you can capture some packets from the other side:
https://wiki.qemu.org/Documentation/Networking#Network_Monitoring

 HTH,
  Thomas

Re: [Qemu-discuss] how to disable DHCP client on qemu

[Thomas Huth]

 Hi,

On 23.01.2018 21:01, Medi Montaseri wrote:
> I am using qemu-system-x86_64
> (x86_64-linux/qemu-native/2.5.0-r1/qemu-2.5.0 ) and multiple network
> interface and in a bridged mode with the host.
[...]
> I don't want qemu to run dhcpc as our own boot scripts will do
> static/dynamic configurations on the tap devices.
> 
> 1) Is there a command line option that I can use to instruct qemu not to
> run any DHCP client ?

Are you sure that the DHCP service is coming from QEMU? As far as I
know, QEMU only provides DHCP for the "-netdev user" interfaces, but not
for tap / bridge.

Are you using libvirt or something similar on top of QEMU? If so, the
DHCP service might be provided by that layer instead, see for example:
https://wiki.libvirt.org/page/VirtualNetworking#DNS_.26_DHCP

 HTH,
  Thomas

Re: [Qemu-discuss] No IP in net interface when using socket netdev

[Thomas Huth]

 Hi,

On 23.01.2018 15:37, Zihan Yang wrote:
> I'm trying to start two VMs V1 and V2, and let them connect through socket.
> 
> I'm using the latest qemu source code cloned from git. Here is the
> configuration of two VM:
> V1: two net cards, one for public Internet using SLIRP, one listening on
> port 1234. The start command is:
> $ qemu-system-x86_64 -m 1024 -enable-kvm -drive file=test.qcow2 \
>  -netdev user,id=realnet0 -device
> e1000e,netdev=realnet0,mac=52:54:00:12:34:56
> \
>  -netdev socket,id=mynet0,listen=:1234 -device
> e1000e,netdev=mynet0,mac=52:54:00:12:34:57
> 
> V2: only one net card, connecting V1 with socket. The start command is:
> $ qemu-system-x86_64 -m 1024 -enable-kvm -drive file=test1.qcow2 \
>  -netdev socket,id=mynet1,connect=127.0.0.1:1234 -device
> e1000e,netdev=mynet1,mac=52:54:00:12:34:58
> 
> However, I find that when I start the V1, there is only only one IP address
> for the net card using SLIRP, and there is no address of another net card.

Unless you've set up a DHCP server in one of the guest, both guests can
not configure an IP address automatically on these interfaces, so it's
normal that you don't get an IP address here. The "user" (SLIRP) network
interface can use the built-in DHCP server from QEMU, but there is no
such feature for the "socket" interfaces.

So you either have got to set static IP addresses here, or you've got to
configure a DHCP server in one of the guests, as far as I can see.

 HTH,
  Thomas

Re: [Qemu-discuss] Setting a interface name with qemu-bridge-helper?

[Thomas Huth]

On 15.01.2018 21:04, Shaun Reitan wrote:
> You can specifiy a ifname is you use -netdev tap however if you try and
> use the bridge-helper script you get an error. Also looking at the code
> of the bridge-helper I can see there is no logic for specificing a name.
>  I've already modified the helper script to now allow a name to be
> passed. I'm just now having difficulty figuring out what sections in the
> qemu source need to be modifed to allow this as well.

Ah, now I see. There is a check in net_init_tap() in net/tap.c, indeed.
I guess you've got to remove the "tap->has_ifname" from this check:

 if (tap->has_ifname || tap->has_script || tap->has_downscript ||
tap->has_vnet_hdr || tap->has_queues || tap->has_vhostfds) {
error_setg(errp, "ifname=, script=, downscript=, vnet_hdr=, "
   "queues=, and vhostfds= are invalid with helper=");
return -1;
}

... and then you could pass "tap->ifname" as additional parameter to
net_bridge_run_helper() which then could pass it as additional argument
to the bridge helper script. ... well, it's just a guess, I haven't
tried it.

  Thomas

Re: [Qemu-discuss] Setting a interface name with qemu-bridge-helper?

[Thomas Huth]

On 14.01.2018 11:25, Narcis Garcia wrote:
> I think vlan number links different VM instances in a same virtual net
> (as physical cables) VM1 & VM2 in vlan=0 ; VM3 in vlan=1

Note sure whether I've got you right, but just in case: The 'vlan'
parameter does not influence any tap/bridge settings. It's an
QEMU-internal thing only. QEMU can emulate network hubs and the vlan
parameter is used to specify the number of the *internal* hub where the
network interface should be connected to.

Since that is pretty confusing (many people get that wrong) and the
'vlan' parameter is named very badly (it has nothing to do with 802.1Q
and other VLAN concecpts), it has been marked as deprecated in the
latest versions of QEMU, and likely will be removed in a future version.
If you're still using it, it might be a good idea to switch now to the
"modern" -netdev syntax instead if possible.

 Regards,
  Thomas

Re: [Qemu-discuss] Setting a interface name with qemu-bridge-helper?

[Thomas Huth]

On 13.01.2018 01:34, Shaun Reitan wrote:
> When starting vm's with '-netdev bridge,id=net0,br=br0' each vm is given
> a tapX interface name and from what I can tell, there is no simple way
> to figure out which interface belongs to which VM.
> 
> I'd like to see a name option added to it which would be passed along to
> the qemu-bridge-helper.  Something like '-netdev
> bridge,id=net0,br=br0,name=vm1net0' or '-netdev
> bridge,id=net0,br=br0,ifname=vm1net0'
> 
> Any reason why setting the tap's interface name was left out before I go
> attempting to patch this functionality in? Or maybe is there a fast and
> simple way to get the tap interface of the VM

I think it should be possible to specify the name of the tap interface
via the "ifname=" parameter, e.g.: -netdev tap,ifname=tap2

In case you already started QEMU without that parameter, you can look up
the tapX name via the "info network" monitor command.

 HTH,
  Thomas

Re: [Qemu-discuss] s390x user-mode working example

[Thomas Huth]

On 24.11.2017 12:19, Alex Kashchenko wrote:
> Unfortunately, I just found that OpenJDK's JIT requires newer
> instruction set than z900:
> 
> $ ./s390x-linux-user/qemu-s390x
> ~/jdk9/build/linux-s390x-normal-server-release/images/jdk/bin/java -version
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (vm_version_s390.hpp:367), pid=26037, tid=26039
> #  guarantee((_features[0] & GnrlInstrExtFacilityMask) ==
> GnrlInstrExtFacilityMask) failed: We no more support older than z10.

That looks like it is missing the so-called "general instruction
extension facility". You might be lucky - that's one of the extensions
that can already be enabled for testing purposes with the "qemu" CPU:
Try to start QEMU with the "-cpu qemu,ginste=true" parameter.
If it then still complains about missing facilities, try "-cpu help" to
list all recognized feature flags.

The following features can already be enabled with the "qemu" CPU (list
has been copy-n-pasted from the sources, but I hope you'll be able to
map it to the output of "-cpu help", too):

S390_FEAT_DAT_ENH,
S390_FEAT_IDTE_SEGMENT,
S390_FEAT_STFLE,
S390_FEAT_EXTENDED_IMMEDIATE,
S390_FEAT_EXTENDED_TRANSLATION_2,
S390_FEAT_EXTENDED_TRANSLATION_3,
S390_FEAT_LONG_DISPLACEMENT,
S390_FEAT_LONG_DISPLACEMENT_FAST,
S390_FEAT_ETF2_ENH,
S390_FEAT_STORE_CLOCK_FAST,
S390_FEAT_MOVE_WITH_OPTIONAL_SPEC,
S390_FEAT_ETF3_ENH,
S390_FEAT_COMPARE_AND_SWAP_AND_STORE,
S390_FEAT_COMPARE_AND_SWAP_AND_STORE_2,
S390_FEAT_GENERAL_INSTRUCTIONS_EXT,
S390_FEAT_EXECUTE_EXT,
S390_FEAT_FLOATING_POINT_SUPPPORT_ENH,
S390_FEAT_STFLE_45,
S390_FEAT_STFLE_49,
S390_FEAT_LOCAL_TLB_CLEARING,
S390_FEAT_STFLE_53,

 HTH,
  Thomas

Re: [Qemu-discuss] s390x user-mode working example

[Thomas Huth]

On 23.11.2017 22:00, Alex Kashchenko wrote:
> Hi,
> 
> I am trying to build qemu-s390x-user static binary to run a hello-world
> program cross-compiled with gcc-s390x-linux-gnu on linux_x86_64.
> 
> I am building qemu with:
> 
> ./configure --static --disable-werror --target-list=s390x-linux-user
> make
> 
> and running example with:
> 
> QEMU_STRACE=1 ./s390x-linux-user/qemu-s390x path/to/s390x-hello
> 
> I tried latest git and a number of v2.x releases without success. Can
> see either hang (on first brk call) or various errors for newer versions
> and "Illegal instruction" for older ones. Tried on ubuntu 16.04 and
> 17.10 without success.
> 
> The same steps worked for me for ppc64le hello-world.
> 
> Any help on this is highly appreciated.

How did you cross-compile your s390x binary? QEMU's CPU emulation only
fully supports the z900 so far (more support is being worked on), so you
should make sure that your program has been compiled for that CPU
architecture, i.e. add "-m64 -march=z900" to your CFLAGS. Does that help?

 Thomas

Re: [Qemu-discuss] Apple hyphervisor.framework availability

[Thomas Huth]

On 23.11.2017 08:36, Brendan Simon (eTRIX) wrote:
> Hi QEMU devs,
> 
> Just wondering when the accelerator for Apple's hypervisor.framework
> (hvf) will hit the git repos to build and try out?
> 
> I get the impression that patches have been submitted, but I can't see
> anything in the repos.  Is there a special branch or fork where these
> patches reside?

According to
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg00415.html
there is a branch in Paolo's repository. hvf apparently hasn't been
merged into the upstream QEMU git repository yet.

 Thomas

Re: [Qemu-discuss] Qemu on windows host is slow

[Thomas Huth]

On 10.11.2017 08:49, mahmood n wrote:
> Hi,
> I have installed qemu on my windows 10 (x64) and I am able to run 
> qemu-system-x86_64 command. Problem is that it is very slow! And when I want 
> to install an Ubuntu as a guest, I have to wait many minutes to see the 
> installation wizard.
> 
> On Linux, I can use -enable-kvm, but here it is not possible. Any advice?

If you're using the latest and greatest version of QEMU, you can have a
try with "--accel hax" on Windows.

 Thomas

Re: [Qemu-discuss] qemu-img: Check failed: No space left on device

[Thomas Huth]

On 19.09.2017 09:06, Nicolas Ecarnot wrote:
> Hello,
> 
> Would it be a better idea I post this question on the devel list?

I'd suggest the qemu-block mailing list:

https://lists.nongnu.org/mailman/listinfo/qemu-block

 Thomas

Re: [Qemu-discuss] Coldfire 5282 Support

[Thomas Huth]

On 13.09.2017 16:31, William Mahoney wrote:
[...]
> By the way, there is a link to a uClinux image on the emu documentation pages 
> but the link times out. Is there a uClinux 5208 kernel image somewhere else? 
> I only wanted to try that to make sure that everything else (serial ports) is 
> set up, etc.

uclinux.org was still available a couple of weeks ago. Let's hope that
it is just temporary offline. If it permanently down, let me know, I
think I've got those images still somewhere on my hard disk...

 Thomas

Re: [Qemu-discuss] Coldfire 5282 Support

[Thomas Huth]

On 12.09.2017 21:05, William Mahoney wrote:
> OK a bit of an update and another question or two. First, you’re right, “it 
> just plain works”. What I’d like to verify today is that I am “doing the 
> right thing” is all. 
> 
> 1) I made a copy of qemu/hw/m68k/mcf5208.c as mcf5282.c and I - for now - 
> changed all 5208 to 5282 inside the source. Threw in some fprintfs while I 
> was at it.
>
> 2) Added mcf5282.o to the Makefile.objs that is in that directory.

That sounds right.

> 3) Went into emu/target/m68k/cpu.c and duplicated (with a name change) the 
> init function for the 5208, then added the 5282 (currently named 
> “m5282-bill”) to the list of m68k_cpus. Took a bit of grepping. 

I think that's likely the right thing to do ... but I currently wonder
whether we really want to have a duplicate entry for each of the MCF
variants, or rather a generic ColdFire V2 core instead (we already have
a generic "cfv4e" for V4, for example). So the "cfv2" core could be
shared between the mcf5208evb and the mcf5282evb machine ...?

> Now I can do 'qemu-system-m68k -cpu m5282-bill -bios /tmp/mybios’ and it 
> stops (gdb) at the init function in my 5282 with everything set and ready to 
> rock and roll.

You likely still ended up with the m5208 machine here. You've got to
select the right machine with "-M mcf5282evb", too. Please also make
sure to remove the "mc->is_default = 1" line from your new machine
(since we likely do not want to change the default machine).

> So after all this description, just a simple question. Is this “how you are 
> supposed to do it”, in general? There’s no master list of dependencies I 
> needed to update, or a Makefile I need to change, or… ? As long as I do 
> another configure to let it know the dependencies, that’s pretty much it, 
> right? Just wanting to do it the correct way for future use.

Right, adding your new board to hw/m68k/Makefile.objs should be
sufficient here.

 Thomas

Re: [Qemu-discuss] cortex M4F support

[Thomas Huth]

On 08.09.2017 09:05, massimiliano cialdi wrote:
> Is cortex M4F supported?
> Which command line parameters?

You can query the list of supported CPUs with "-cpu ?" like this:

qemu-system-aarch64 -M virt -cpu ?

There seems to be a "cortex-m4" available ... is that close enough to
the "M4F"?

 Thomas