qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/5] Add "info capabilities" monitor command


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 0/5] Add "info capabilities" monitor command
Date: Thu, 13 Nov 2008 19:49:32 +0200

On 11/13/08, Mark McLoughlin <address@hidden> wrote:
> 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.

Good idea, though perhaps the output should be compatible with the
config file, which we don't have yet.

For sparc-softmmu I get:
(qemu) info capabilities
[qemu]
accel=
arch=sparc
cpu=Fujitsu MB86900,Fujitsu MB86904,Fujitsu MB86907,LSI L64811,Cypress
CY7C601,Cypress CY7C611,TI SuperSparc II,TI MicroSparc I,TI MicroSparc
II,TI MicroSparc IIep,TI SuperSparc 40,TI SuperSparc 50,TI SuperSparc
51,TI SuperSparc 60,TI SuperSparc 61,Ross RT625,Ross RT620,BIT
B5010,Matsushita MN10501,Weitek W8601,LEON2,LEON3
machines=SS-5,SS-10,SS-600MP,SS-20,SS-2,Voyager,LX,SS-4,SPARCClassic,SPARCbook,SS-1000,SS-2000

[machine]
name=SS-5
max_cpus=1
nic_models=

[machine]
name=SS-10
max_cpus=4
nic_models=

[machine]
name=SS-600MP
max_cpus=4
nic_models=

[machine]
name=SS-20
max_cpus=4
nic_models=

[machine]
name=SS-2
max_cpus=0
nic_models=

[machine]
name=Voyager
max_cpus=0
nic_models=

[machine]
name=LX
max_cpus=0
nic_models=

[machine]
name=SS-4
max_cpus=0
nic_models=

[machine]
name=SPARCClassic
max_cpus=0
nic_models=

[machine]
name=SPARCbook
max_cpus=0
nic_models=

[machine]
name=SS-1000
max_cpus=8
nic_models=

[machine]
name=SS-2000
max_cpus=20
nic_models=

[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
network=tap,socket,user,none
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_prom_envs=128
max_scsi_devs=7
max_serial_ports=4
max_usb_devs=8

Sparc64:
(qemu) info capabilities
[qemu]
accel=
arch=sparc64
cpu=Fujitsu Sparc64,Fujitsu Sparc64 III,Fujitsu Sparc64 IV,Fujitsu
Sparc64 V,TI UltraSparc I,TI UltraSparc II,TI UltraSparc IIi,TI
UltraSparc IIe,Sun UltraSparc III,Sun UltraSparc III Cu,Sun UltraSparc
IIIi,Sun UltraSparc IV,Sun UltraSparc IV+,Sun UltraSparc IIIi+,Sun
UltraSparc T1,Sun UltraSparc T2,NEC UltraSparc I
machines=sun4u,sun4v,Niagara

[machine]
name=sun4u
max_cpus=1
nic_models=ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet

[machine]
name=sun4v
max_cpus=1
nic_models=ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet

[machine]
name=Niagara
max_cpus=1
nic_models=ne2k_pci,i82551,i82557b,i82559er,rtl8139,e1000,pcnet

[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
network=tap,socket,user,none
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_prom_envs=128
max_scsi_devs=7
max_serial_ports=4
max_usb_devs=8

The lists would be more readable if there were a space after comma.

nic_models is empty for Sun4m.

max_cpus can be 1 or 0, both should be 1.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]