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
>> controll
-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
> suppl
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, the
Alexander Graf writes:
> Am 14.11.2013 um 20:25 schrieb Alexey Kardashevskiy :
>
>> On 11/15/2013 10:03 AM, Peter Maydell wrote:
>>> On 14 November 2013 22:32, Benjamin Herrenschmidt
>>> wrote:
On Thu, 2013-11-14 at 17:23 -0500, Alexander Graf wrote:
> Yes. But I think it's the correct
Am 14.11.2013 um 20:25 schrieb Alexey Kardashevskiy :
> On 11/15/2013 10:03 AM, Peter Maydell wrote:
>> On 14 November 2013 22:32, Benjamin Herrenschmidt
>> 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 a
On 11/15/2013 10:03 AM, Peter Maydell wrote:
> On 14 November 2013 22:32, Benjamin Herrenschmidt
> 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.
On Thu, 2013-11-14 at 23:03 +, Peter Maydell wrote:
> On 14 November 2013 22:32, Benjamin Herrenschmidt
> 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 w
On 14 November 2013 22:32, Benjamin Herrenschmidt
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 P
On Thu, Nov 14, 2013 at 2:32 PM, Benjamin Herrenschmidt
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 le
On Thu, Nov 14, 2013 at 2:41 PM, Alexander Graf wrote:
>
>
> Am 14.11.2013 um 17:32 schrieb 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
Am 14.11.2013 um 17:32 schrieb 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
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 -nodefau
On 14.11.2013, at 15:28, Benjamin Herrenschmidt
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 c
On 14 November 2013 20:28, Benjamin Herrenschmidt
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 con
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
[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
Am 14.11.2013 um 04:37 schrieb 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 creat
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
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.
>
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, yab
20 matches
Mail list logo
