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

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

[Alexey Kardashevskiy]

Hi everyone.

Here is a problem with the SPAPR machine and a libvirt's habit to use
"-nodefaults".

When we run QEMU with "-vga std", a VGA device is created from the
machine_init callback and if VGA is added, then we automatically add a PCI
USB OHCI adapter with a keyboard and everybody (SLOF, yaboot, guest kernel)
is happy - there are both input and output devices.

However libvirt uses "-device VGA" to create a VGA device. In this case the
actual VGA device is created in vl.c and we (SPAPR) do not have control
over this process so we do not automatically create anything in addition to
VGA. As a result, yaboot fails as there is no input device.

x86 creates a whole bunch of various devices including a keyboard
controller (i8042) even with "-nodefaults" but this is not true for SPAPR.

Since we (POWERPC folks) want everything to work as close to x86 as
possible, we need to do something about it :)

So the question is - is there any proper (i. e. qemu-upstreamable) way to
detect a VGA device presence and create additional devices (OHCI, keyboard,
mouse) as "-vga" does it now? The machine reset callback is too late for that.

Or we should just print an error (in QEMU or SLOF) and do nothing and let
the user configure all required devices in libvirt?


-- 
Alexey

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

[Benjamin Herrenschmidt]

On Thu, 2013-11-14 at 16:01 +1100, Alexey Kardashevskiy wrote:
> So the question is - is there any proper (i. e. qemu-upstreamable) way to
> detect a VGA device presence and create additional devices (OHCI, keyboard,
> mouse) as "-vga" does it now? The machine reset callback is too late for that.
> 
> Or we should just print an error (in QEMU or SLOF) and do nothing and let
> the user configure all required devices in libvirt?

My opinion is that we should always create a PAPR vty...

libvirt creating VGA devices is stupid... I understand x86's get upset when
they don't have one but it's useless on power and adds its own problems.

So libvirt should be fixed not to do that

Cheers,
Ben.

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

[Alexey Kardashevskiy]

On 11/14/2013 05:01 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-11-14 at 16:01 +1100, Alexey Kardashevskiy wrote:
>> So the question is - is there any proper (i. e. qemu-upstreamable) way to
>> detect a VGA device presence and create additional devices (OHCI, keyboard,
>> mouse) as "-vga" does it now? The machine reset callback is too late for that.
>>
>> Or we should just print an error (in QEMU or SLOF) and do nothing and let
>> the user configure all required devices in libvirt?
> 
> My opinion is that we should always create a PAPR vty...
> 
> libvirt creating VGA devices is stupid... I understand x86's get upset when
> they don't have one but it's useless on power and adds its own problems.

The RHEL6.5 test mode installer is pretty limited compared to the graphical
version. And, with libvirt, it is not always easy to use VNC provided by
the installer. Having VGA is quite nice option.


> So libvirt should be fixed not to do that

The user decided to use VGA, not libvirt (which does not create VGA by
default).


-- 
Alexey

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

[Alexander Graf]

Am 14.11.2013 um 04:37 schrieb Alexey Kardashevskiy <aik@ozlabs.ru>:

> On 11/14/2013 05:01 PM, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-11-14 at 16:01 +1100, Alexey Kardashevskiy wrote:
>>> So the question is - is there any proper (i. e. qemu-upstreamable) way to
>>> detect a VGA device presence and create additional devices (OHCI, keyboard,
>>> mouse) as "-vga" does it now? The machine reset callback is too late for that.
>>> 
>>> Or we should just print an error (in QEMU or SLOF) and do nothing and let
>>> the user configure all required devices in libvirt?
>> 
>> My opinion is that we should always create a PAPR vty...
>> 
>> libvirt creating VGA devices is stupid... I understand x86's get upset when
>> they don't have one but it's useless on power and adds its own problems.
> 
> The RHEL6.5 test mode installer is pretty limited compared to the graphical
> version. And, with libvirt, it is not always easy to use VNC provided by
> the installer. Having VGA is quite nice option.
> 
> 
>> So libvirt should be fixed not to do that
> 
> The user decided to use VGA, not libvirt (which does not create VGA by
> default).

In general we try to split cleverness between two different cases.

1) normal direct QEMU command line usage

Here we want to make life easy for a user and give him some help. That's why we automatically create a keyboard and USB controller when we see that he wants to use VGA.

2) -nodefaults

This mode is meant to pass full control to a management stack which wants to implement its own cleverness. The less QEMU tries to be smart, the more consistent we are in our interface. This mode really is meant as to tell QEMU to allow you to shoot yourself in the foot.

So in this case, the proper fix is to add the logic to libvirt. It asks for a machine without cleverness applied, so it needs to do all of the magic itself. It already does this for the mouse btw (-usbdevice tablet) to allow for an absolute pointer. It's only sensible to ask them to do the keyboard too. In this case, x86 is the inconsistent platform.


Alex

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

[Benjamin Herrenschmidt]

On Thu, 2013-11-14 at 08:04 -0500, Alexander Graf wrote:
> 2) -nodefaults
> 
> This mode is meant to pass full control to a management stack which
> wants to implement its own cleverness. The less QEMU tries to be
> smart, the more consistent we are in our interface. This mode really
> is meant as to tell QEMU to allow you to shoot yourself in the foot.
> 
> So in this case, the proper fix is to add the logic to libvirt. It
> asks for a machine without cleverness applied, so it needs to do all
> of the magic itself. It already does this for the mouse btw
> (-usbdevice tablet) to allow for an absolute pointer. It's only
> sensible to ask them to do the keyboard too. In this case, x86 is the
> inconsistent platform.

I knew you were going to answer that :-)

Note that this is inconsistent with x86 which always create a number
of devices with -nodefaults ... such as a keyboard controller.

Cheers,
Ben.

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

[Peter Maydell]

On 14 November 2013 20:28, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Thu, 2013-11-14 at 08:04 -0500, Alexander Graf wrote:
>> 2) -nodefaults
>>
>> This mode is meant to pass full control to a management stack which
>> wants to implement its own cleverness. The less QEMU tries to be
>> smart, the more consistent we are in our interface. This mode really
>> is meant as to tell QEMU to allow you to shoot yourself in the foot.

> Note that this is inconsistent with x86 which always create a number
> of devices with -nodefaults ... such as a keyboard controller.

If you can't physically have an x86 PC without a keyboard
controller I'm not sure it makes any sense for QEMU's PC
model to be instantiated without one. This makes sense at
the moment since -device really only works for pluggable
buses anyway, so there's no way for a management stack
to provide anything that's really an integrated part of the
main system if we don't always create it.

I know people have tossed around the idea of being able
to create an entire board model from configfile and command
line; however we don't have that today...

-- PMM

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

[Alexander Graf]

On 14.11.2013, at 15:28, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Thu, 2013-11-14 at 08:04 -0500, Alexander Graf wrote:
>> 2) -nodefaults
>> 
>> This mode is meant to pass full control to a management stack which
>> wants to implement its own cleverness. The less QEMU tries to be
>> smart, the more consistent we are in our interface. This mode really
>> is meant as to tell QEMU to allow you to shoot yourself in the foot.
>> 
>> So in this case, the proper fix is to add the logic to libvirt. It
>> asks for a machine without cleverness applied, so it needs to do all
>> of the magic itself. It already does this for the mouse btw
>> (-usbdevice tablet) to allow for an absolute pointer. It's only
>> sensible to ask them to do the keyboard too. In this case, x86 is the
>> inconsistent platform.
> 
> I knew you were going to answer that :-)
> 
> Note that this is inconsistent with x86 which always create a number
> of devices with -nodefaults ... such as a keyboard controller.

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.


Alex

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

[Benjamin Herrenschmidt]

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...

Cheers,
Ben.

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

[Alexander Graf]

Am 14.11.2013 um 17:32 schrieb Benjamin Herrenschmidt <benh@kernel.crashing.org>:

> 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...

There is a set of devices that is always part of your machine. For the PC, this is the PCI complex and SuperIO (including the keyboard controller).

For pseries, we don't have that chip. We could simulate similar behavior through a usb controller and keyboard. But those are devices that not every pseries VM will want to have.

So it really is libvirt's or the xml's job to add these.

Even on x86 there are Atom chips out now that run without SuperIO, so we might eventually have an x86 machine type without keyboard too, who knows.


Alex

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

[Anthony Liguori]

On Thu, Nov 14, 2013 at 2:41 PM, Alexander Graf <agraf@suse.de> wrote:
>
>
> Am 14.11.2013 um 17:32 schrieb Benjamin Herrenschmidt <benh@kernel.crashing.org>:
>
>> 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...
>
> There is a set of devices that is always part of your machine. For the PC, this is the PCI complex and SuperIO (including the keyboard controller).
>
> For pseries, we don't have that chip. We could simulate similar behavior through a usb controller and keyboard. But those are devices that not every pseries VM will want to have.
>
> So it really is libvirt's or the xml's job to add these.
>
> Even on x86 there are Atom chips out now that run without SuperIO, so we might eventually have an x86 machine type without keyboard too, who knows.

As long as it's x86, there will always be a keyboard controller if you
ever want to support more than 1MB of RAM properly since the keyboard
controller is used to enable the a20 bit.

Regards,

Anthony Liguori

>
> Alex
>

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

[Paolo Bonzini]

Il 14/11/2013 23:45, Anthony Liguori ha scritto:
> As long as it's x86,

You mean "as long as it's PC" but...

> there will always be a keyboard controller if you
> ever want to support more than 1MB of RAM properly since the keyboard
> controller is used to enable the a20 bit.

... not really, there is port 92h too.  Or you could make the board
always enable it.

Paolo

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

[Alexey Kardashevskiy]

On 15.11.2013 23:04, Paolo Bonzini wrote:
> Il 14/11/2013 23:45, Anthony Liguori ha scritto:
>> As long as it's x86,
> 
> You mean "as long as it's PC" but...
> 
>> there will always be a keyboard controller if you
>> ever want to support more than 1MB of RAM properly since the keyboard
>> controller is used to enable the a20 bit.
> 
> ... not really, there is port 92h too.  Or you could make the board
> always enable it.


http://en.wikipedia.org/wiki/A20_line is saying that this was removed
from Nehalem :)



-- 
With best regards

Alexey Kardashevskiy -- icq: 52150396

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

[Anthony Liguori]

On Thu, Nov 14, 2013 at 2:32 PM, 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...

Because pseries is not x86.  This is expected and okay.

Regards,

Anthony Liguori

> Cheers,
> Ben.
>
>
>

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

[Peter Maydell]

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 ordar 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 :-)

-- PMM

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

[Benjamin Herrenschmidt]

On Thu, 2013-11-14 at 23:03 +0000, 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 ordar 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 :-)

Ok, as long as everybody agrees then I don't have a problem with that,
but we'll need libvirt to grow some smarts.

Alexey, can you handle that ?

Cheers,
Ben.

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

[Alexey Kardashevskiy]

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)?


-- 
Alexey

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

[Alexander Graf]

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)?

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.


Alex

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

[Markus Armbruster]

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.

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]

[adding libvirt]

On 11/13/2013 10:01 PM, Alexey Kardashevskiy wrote:
> Hi everyone.
> 
> Here is a problem with the SPAPR machine and a libvirt's habit to use
> "-nodefaults".
> 
> When we run QEMU with "-vga std", a VGA device is created from the
> machine_init callback and if VGA is added, then we automatically add a PCI
> USB OHCI adapter with a keyboard and everybody (SLOF, yaboot, guest kernel)
> is happy - there are both input and output devices.
> 
> However libvirt uses "-device VGA" to create a VGA device. In this case the
> actual VGA device is created in vl.c and we (SPAPR) do not have control
> over this process so we do not automatically create anything in addition to
> VGA. As a result, yaboot fails as there is no input device.
> 
> x86 creates a whole bunch of various devices including a keyboard
> controller (i8042) even with "-nodefaults" but this is not true for SPAPR.

Then libvirt needs to be taught to provide the same devices via -device
that would be present during -vga.

> 
> Since we (POWERPC folks) want everything to work as close to x86 as
> possible, we need to do something about it :)

Hmm, but adding automatic devices in a future qemu release compared to
what you do now could be a regression - once libvirt is taught how to
provide the correct devices for the qemu that exists now, wouldn't that
mean that your automatic device adding creates duplicates?

Libvirt uses -nodefaults for a reason - we really don't like automatic
devices (especially when the set of WHAT is automatic is prone to change
between qemu builds), and would much rather call out everything
explicitly so that we can guarantee guest ABI stability across qemu
upgrades.

> 
> So the question is - is there any proper (i. e. qemu-upstreamable) way to
> detect a VGA device presence and create additional devices (OHCI, keyboard,
> mouse) as "-vga" does it now? The machine reset callback is too late for that.
> 
> Or we should just print an error (in QEMU or SLOF) and do nothing and let
> the user configure all required devices in libvirt?

I'm in favor of printing an error if not enough devices were supplied,
and fixing libvirt to supply the correct devices when it doesn't use -vga.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

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

[Paolo Bonzini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 14/11/2013 14:11, Eric Blake ha scritto:
>>> Or we should just print an error (in QEMU or SLOF) and do
>>> nothing and let the user configure all required devices in
>>> libvirt?
> I'm in favor of printing an error if not enough devices were
> supplied, and fixing libvirt to supply the correct devices when it
> doesn't use -vga.

It's not an error to create a system with a VGA and a mouse but with
no keyboard.  Maybe it's somewhat weird for a pSeries, but it's
definitely a configuration that can work.

Paolo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShg7NAAoJEBvWZb6bTYbyhGMP/Avd+isN55amTIultiXRtnQD
wT8A57eMJ8IU3RsSxqwqaDYhOkaCPGnTQsgZmbENEjcH+TcZOPA80f5GKHILeH2H
wURF4IhJ2ZQBthnjsnJV3wMPjFbTZ5bonnruWOjcMp03KFq1rDvGkc5ZCJ4H+3g2
mupL8fZbX7BSbzK6K1pii9PxsWQUvfssQARAp1KgFP0PtraP/+9AvSzjoSCH3c5K
yi48HHlBzDoLo8mzAuc6iIPVmD+KGLDbzqAM+pzcFxSRUS2xWtmymULk0u06jfEM
0190dadkDaVimQ4OjDWrx0qSYxXjrU2YSQM/xvm9HzIlGOOUDCo3ujBjZjmXusqR
OkP1+B+GFRNmbBrxUA7wTKsr3hSznoj2pUNgKacr0EOcMqT1Nwq7HuklPXuOUH/0
6n2h2QjsSfvzOE4+KLZZv9TP0Tj0QcgKOZfxlvKcIdumHB24wxZALyKHu6Umh/Uk
ANt9fD2alTAH2zpU+SAJeXVcvlglMhWpzRHM9c0ML2EAbLXs5atJFkAhlycn5yQK
nq3tEVQRBpdGo8/ETzzhbBc0bKXgE8cztEk0QAJm5i/4J6eSatImjCYrxEyeZsq9
AQep6ZoK492bKlFQt93ERTLjG8mD8qOWmv31nkbN+jsnbNFQo5VLBxvuoJqahezY
R9tSYYBKldCoK+b2OVgl
=nuI7
-----END PGP SIGNATURE-----