Skip to content

Add "info capabilities" monitor command

Mark McLoughlin qemu-devel 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest5 patches 25 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/5Re-factor nic model listinghw/boards.h hw/mips_malta.c hw/pc.c +9 more+61 -207 replies
2/5Add cpu_list() for any targets that don't already have ittarget-alpha/cpu.h target-alpha/translate.c target-cris/cpu.h +4 more+25 -30 replies
3/5Rename xxx_cpu_list() to cpu_xxx_list()target-arm/cpu.h target-arm/helper.c target-i386/cpu.h +9 more+18 -220 replies
4/5Add new cpu_names() functiontarget-alpha/cpu.h target-alpha/translate.c target-arm/cpu.h +15 more+134 -02 replies
5/5monitor: add "info capabilities" commandconsole.h hw/boards.h hw/bt.h +9 more+288 -86 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [Qemu-devel] [PATCH 0/5] Add "info capabilities" monitor command

Hi,

Management tools need to be able to handle different versions of qemu equally well. Such a tool might need to know whether a given version supports a recently added command line option, whether it was built with kqemu support or who many vcpus is allowed.

One example of this is libvirt which does "qemu -help" and looks at the version string and which command line options are included in the output. That's a hack that works pretty well, but clearly "qemu -help" shouldn't be considered a stable interface.

This came up recently in the context of GSO support the KVM virtio network device. Essentially, libvirt needs to know whether qemu will be able to handle a tapfd with the IFF_VNET_HDR flag set. Adding something about IFF_VNET_HDR to the -help output was rejected as taking an ugly hack way too far :-)

The proposed solution is to add a new monitor command which will list exactly what this qemu binary is capable of. Rather than include every possible capability, I've limited it to:

1) New features; if a version of qemu supports the capabilities info command, you can assume that it also supports features that were added before that.

2) Compile time configurables which affect what features can be requested on the command line - e.g. kqemu support

3) Magic numbers; a managment tool might know that qemu only supports 2 IDE devices - and that may never change - but it's much nicer if the tool can be coded generically rather than hardcoding a magic number.

The patch implementing this isn't perfect by any means, but since this could be implemented in so many different ways I thought I'd post it and get people's feedback.

Cheers,
Mark.

Example output:

[qemu]
accel=kqemu,kvm
arch=x86_64 cpu=qemu64,core2duo,qemu32,coreduo,486,pentium,pentium2,pentium3,athlon,n270 machines=pc,isapc

[machine]
name=pc
max_cpus=255 nic_models=ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet

[machine]
name=isapc
max_cpus=1
nic_models=ne2k_isa

[devices]
bluetooth=hci_null,hci_vlan,vhci_vlan,keyboard char=null,vc,tcp,telnet,mon,unix,file,pipe,pty,stdio,dev_parport,dev_tty drive_cache=off,none,writethrough,writeback drive_if=ide,scsi,floppy,pflash,mtd,sd graphics=nographics,graphics,curses,vnc,vnc_tls network=tap,socket,user,none
soundhw=pcspk,sb16,es1370
vga=std,cirrus,vmware

[limits]
max_boot_dev=q
max_bluetooth_devs=10
max_drives=32
max_ide_devs=2
max_net_clients=32
max_nics=8
max_option_roms=16
max_parallel_ports=3
max_scsi_devs=7
max_serial_ports=4
max_usb_devs=8