Alexander Graf ag...@suse.de writes:
Am 14.11.2013 um 20:25 schrieb Alexey Kardashevskiy a...@ozlabs.ru:
On 11/15/2013 10:03 AM, Peter Maydell wrote:
On 14 November 2013 22:32, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2013-11-14 at 17:23 -0500, Alexander Graf 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
-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
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
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?
Am 14.11.2013 um 04:37 schrieb Alexey Kardashevskiy a...@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
[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
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
On 14 November 2013 20:28, Benjamin Herrenschmidt
b...@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
On 14.11.2013, at 15:28, Benjamin Herrenschmidt b...@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
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
Am 14.11.2013 um 17:32 schrieb Benjamin Herrenschmidt
b...@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
On Thu, Nov 14, 2013 at 2:41 PM, Alexander Graf ag...@suse.de wrote:
Am 14.11.2013 um 17:32 schrieb Benjamin Herrenschmidt
b...@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
On Thu, Nov 14, 2013 at 2:32 PM, Benjamin Herrenschmidt
b...@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
On 14 November 2013 22:32, Benjamin Herrenschmidt
b...@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
On Thu, 2013-11-14 at 23:03 +, Peter Maydell wrote:
On 14 November 2013 22:32, Benjamin Herrenschmidt
b...@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
On 11/15/2013 10:03 AM, Peter Maydell wrote:
On 14 November 2013 22:32, Benjamin Herrenschmidt
b...@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
Am 14.11.2013 um 20:25 schrieb Alexey Kardashevskiy a...@ozlabs.ru:
On 11/15/2013 10:03 AM, Peter Maydell wrote:
On 14 November 2013 22:32, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2013-11-14 at 17:23 -0500, Alexander Graf wrote:
Yes. But I think it's the correct
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,
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
20 matches
Mail list logo
