Re: [Qemu-devel] -vga std vs. -device VGA

[Markus Armbruster <armbru@redhat.com>]

Alexander Graf <agraf@suse.de> writes:

> Am 14.11.2013 um 20:25 schrieb Alexey Kardashevskiy <aik@ozlabs.ru>:
>
>> On 11/15/2013 10:03 AM, Peter Maydell wrote:
>>> On 14 November 2013 22:32, Benjamin Herrenschmidt
>>> <benh@kernel.crashing.org> wrote:
>>>> On Thu, 2013-11-14 at 17:23 -0500, Alexander Graf wrote:
>>>>> Yes. But I think it's the correct thing to do in this case. X86 also
>>>>> doesn't create a USB controller like we would have to. Our pseries
>>>>> platform just doesn't have a legacy PC/AT keyboard controller.
>>>> 
>>>> Sure, but that implies that -nodefaults -device VGA creates a working
>>>> usable machine on x86 and not on pseries...
>>> 
>>> Sounds plausible. Anything using -nodefaults has to have
>>> knowledge of every QEMU machine type it wants to use
>>> so it can know which devices need adding in order to get
>>> various functionality. ('-device VGA' doesn't work at all on
>>> some, for instance). If you ask for full manual control, you
>>> get full manual control :-)
>> 
>> That is ok and I asked our libvirt person to fix it (Hi Li :) ).
>> 
>> What I still do not completely understand is the principle used about
>> automatic device creation. Specifically, "-device VGA" creates only VGA
>> (and that is understandable) but "-vga std" creates more devices, if if
>> used together with "-nodefaults".
>> 
>> Is it because "-device" must create only what it is told to create and
>> others non-"-device" options (-usb? -vga? -machine ...? any!) can
>> auto-create whatever they want (well, what seems reasonable to create for
>> the specific arch)?

Semantics of -device are straightforward by design: add this device, no
more, no less, no ifs, no buts.

There are a number of convenience and legacy options to create devices.

* Some of them are desugared by generic code into an equivalent -device
  option (example: -balloon).  Simple, clean semantics.

* Some are parsed by generic code, then passed to device code (example:
  -soundhw), or left in a place where device code can find it (example:
  -drive if=scsi).  Which device model processes the option can depend
  on what devices are registered (-soundhw), or actually created (-drive
  if=scsi).  Device code interprets the arguments (if any) however it
  sees fit.  If there's no suitable device, a fatal error is reported
  for some options (-soundhw), while others get silently ignored.

* Some are parsed by generic code, then left in a place where board code
  can find them (example: -serial left in serial_hds[], -vga left in
  vga_interface_type, -drive if=ide left behind drive_get(IF_IDE, ...)).
  What the board does with them is entirely up to the board.

  Options the board doesn't know are ignored silently.  Invalid known
  options may be ignored silently, ignored with a warning, or treated as
  fatal error.  For valid known options, the board creates whatever
  devices it sees fit.  This can be plain (create the appropriate serial
  device with default properties), or it can be funky (create devices
  "VGA", "usb-kbd" and "usb-mouse").

Guess which of the three I like best.

Regarding board code interpreting options in funky ways: in my opinion,
funky should be avoided.  Doesn't mean the problem isn't worthy
(providing nice defaults with -M pseries certainly is), just that a
non-funky solution would be cleaner.

Without -nodefaults, you get a board that may include some optional
devices believed to be convenient for most users.  With -nodefaults, you
get a device without them.  Details:

* Suppress the default serial device, just like -serial, -device
  isa-serial, and machine->no_serial do.

* Suppress the default parallel device, just like -serial, -device
  isa-parallel, and machine->no_parallel do.

* Suppress the default virtcon device, just like -virtiocon, -device
  virtio-serial-pci, -device virtio-serial-s390, -device virtio-serial,
  and !machine->use_virtcon do.

* Much more; I trust you get the picture.

When the optional device is created by board code (which is typically
the case), the exact effect of -nodefaults on it depends on the board.

> Yeah, you can use QEMU as the interface to the user, then you want to
> be easy and smart. Or you can use QEMU as interface to a management
> stack. Then you want to be as precise and deterministric as
> possible. -device falls into the latter category.

Yes, although opinions on what exactly is "easy" or "smart" are bound to
differ at times ;)

Management applications generally want -device with -nodefaults for full
control and predictability, especially across QEMU updates.