From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L0fLb-00041T-Iv for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:47:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L0fLZ-0003zP-5n for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:47:10 -0500 Received: from [199.232.76.173] (port=36050 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L0fLY-0003zA-RL for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:47:08 -0500 Received: from mail14.svc.cra.dublin.eircom.net ([159.134.118.30]:44466) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L0fLY-0000A9-Ts for qemu-devel@nongnu.org; Thu, 13 Nov 2008 11:47:09 -0500 From: Mark McLoughlin Date: Thu, 13 Nov 2008 16:45:58 +0000 Message-Id: <1226594763-2304-1-git-send-email-markmc@redhat.com> In-Reply-To: <> References: <> Subject: [Qemu-devel] [PATCH 0/5] Add "info capabilities" monitor command Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org 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