All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Jia Liu <proljc@gmail.com>, "Michael S. Tsirkin" <mst@redhat.com>,
	Alexey Kardashevskiy <aik@ozlabs.ru>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	qemu-devel@nongnu.org, Michael Roth <mdroth@linux.vnet.ibm.com>,
	Beniamino Galvani <b.galvani@gmail.com>,
	libvir-list@redhat.com, Greg Kurz <groug@kaod.org>,
	qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	Laine Stump <laine@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Andrea Bolognani <abologna@redhat.com>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-arm] [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines')
Date: Thu, 24 Nov 2016 14:39:51 +0100	[thread overview]
Message-ID: <87oa15dmjc.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20161123171047.GA27297@thinpad.lan.raisama.net> (Eduardo Habkost's message of "Wed, 23 Nov 2016 15:10:47 -0200")

Eduardo Habkost <ehabkost@redhat.com> writes:

> (CCing the maintainers of the machines that crash when using
> -nodefaults)
>
> On Tue, Nov 22, 2016 at 08:34:50PM -0200, Eduardo Habkost wrote:
> [...]
>> "default defaults" vs "-nodefault defaults"
>> -------------------------------------------
>> 
>> Two bad news:
>> 
>> 1) We need to differentiate buses created by the machine with
>>    "-nodefaults" and buses that are created only without
>>    "-nodefaults".
>> 
>> libvirt use -nodefaults when starting QEMU, so knowing which
>> buses are available when using -nodefaults is more interesting
>> for them.

Yes.

>> Other software, on the other hand, might be interested in the
>> results without -nodefaults.

Maybe.

Related: other machine options, such as usb=on.

>> We need to be able model both cases in the new interface.
>> Suggestions are welcome.
>
> The good news is that the list is short. The only[1] machines
> where the list of buses seem to change when using -nodefaults
> are:
>
> * mpc8544ds
> * ppce500
> * mpc8544ds
> * ppce500
> * s390-ccw-virtio-*
>
> On all cases above, the only difference is that a virtio bus is
> available if not using -nodefaults.
>
> Considering that the list is short, I plan to rename
> 'supported-device-types' to 'always-available-buses', and
> document that it will include only the buses that are not
> disabled by -nodefaults.
>
> [1] I mean, the only ones from the set that don't crash with
>     -nodefaults. The ones below could not be tested:
>
>> 2) A lot of machine-types won't start if using
>>    "-nodefaults -machine <machine>" without any extra devices or
>>    drives.
>> 
>> Lots of machines require some drives or devices to be created
>> (especially ARM machines that require a SD drive to be
>> available).
>> 
>> Some machines will make QEMU exit, some of them simply segfault.
>> I am looking for ways to work around it so we can still validate
>> -nodefaults-based info on the test code.
>
> The following machines won't work with -nodefaults:
>
> These make QEMU segfault:
> * cubieboard
> * petalogix-ml605
> * or32-sim
> * virtex-ml507
> * Niagara

Bugs.

> These exit with a "missing SecureDigital device" error:
> * akita
> * borzoi
> * cheetah
> * connex
> * mainstone
> * n800
> * n810
> * spitz
> * sx1
> * sx1-v1
> * terrier
> * tosa
> * verdex
> * z2

Bugs only if there is no other way to provide the SD device.  I believe
some variation if -drive if=sd,... should do fine.

WARNING: multiple messages have this Message-ID (diff)
From: Markus Armbruster <armbru@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, Marcel Apfelbaum <marcel@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Jia Liu <proljc@gmail.com>, Alexey Kardashevskiy <aik@ozlabs.ru>,
	Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
	Michael Roth <mdroth@linux.vnet.ibm.com>,
	Greg Kurz <groug@kaod.org>,
	Beniamino Galvani <b.galvani@gmail.com>,
	libvir-list@redhat.com,
	Alex Williamson <alex.williamson@redhat.com>,
	qemu-arm@nongnu.org, qemu-ppc@nongnu.org,
	Laine Stump <laine@redhat.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Andrea Bolognani <abologna@redhat.com>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] -nodefaults and available buses (was Re: [RFC 00/15] qmp: Report supported device types on 'query-machines')
Date: Thu, 24 Nov 2016 14:39:51 +0100	[thread overview]
Message-ID: <87oa15dmjc.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20161123171047.GA27297@thinpad.lan.raisama.net> (Eduardo Habkost's message of "Wed, 23 Nov 2016 15:10:47 -0200")

Eduardo Habkost <ehabkost@redhat.com> writes:

> (CCing the maintainers of the machines that crash when using
> -nodefaults)
>
> On Tue, Nov 22, 2016 at 08:34:50PM -0200, Eduardo Habkost wrote:
> [...]
>> "default defaults" vs "-nodefault defaults"
>> -------------------------------------------
>> 
>> Two bad news:
>> 
>> 1) We need to differentiate buses created by the machine with
>>    "-nodefaults" and buses that are created only without
>>    "-nodefaults".
>> 
>> libvirt use -nodefaults when starting QEMU, so knowing which
>> buses are available when using -nodefaults is more interesting
>> for them.

Yes.

>> Other software, on the other hand, might be interested in the
>> results without -nodefaults.

Maybe.

Related: other machine options, such as usb=on.

>> We need to be able model both cases in the new interface.
>> Suggestions are welcome.
>
> The good news is that the list is short. The only[1] machines
> where the list of buses seem to change when using -nodefaults
> are:
>
> * mpc8544ds
> * ppce500
> * mpc8544ds
> * ppce500
> * s390-ccw-virtio-*
>
> On all cases above, the only difference is that a virtio bus is
> available if not using -nodefaults.
>
> Considering that the list is short, I plan to rename
> 'supported-device-types' to 'always-available-buses', and
> document that it will include only the buses that are not
> disabled by -nodefaults.
>
> [1] I mean, the only ones from the set that don't crash with
>     -nodefaults. The ones below could not be tested:
>
>> 2) A lot of machine-types won't start if using
>>    "-nodefaults -machine <machine>" without any extra devices or
>>    drives.
>> 
>> Lots of machines require some drives or devices to be created
>> (especially ARM machines that require a SD drive to be
>> available).
>> 
>> Some machines will make QEMU exit, some of them simply segfault.
>> I am looking for ways to work around it so we can still validate
>> -nodefaults-based info on the test code.
>
> The following machines won't work with -nodefaults:
>
> These make QEMU segfault:
> * cubieboard
> * petalogix-ml605
> * or32-sim
> * virtex-ml507
> * Niagara

Bugs.

> These exit with a "missing SecureDigital device" error:
> * akita
> * borzoi
> * cheetah
> * connex
> * mainstone
> * n800
> * n810
> * spitz
> * sx1
> * sx1-v1
> * terrier
> * tosa
> * verdex
> * z2

Bugs only if there is no other way to provide the SD device.  I believe
some variation if -drive if=sd,... should do fine.

  parent reply	other threads:[~2016-11-24 13:40 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22  1:11 [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Eduardo Habkost
2016-11-22  1:11 ` [Qemu-devel] [RFC 01/15] qemu.py: Make logging optional Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 02/15] qtest.py: Support QTEST_LOG environment variable Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 03/15] qtest.py: make logging optional Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 04/15] qtest.py: Make 'binary' parameter optional Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 05/15] tests: Add rules to non-gtester qtest test cases Eduardo Habkost
2016-11-22 13:34   ` Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 06/15] qdev: Add device_type field to BusClass Eduardo Habkost
2016-11-24 16:48   ` Cornelia Huck
2016-11-24 17:37     ` Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 07/15] machine: Add MachineClass::default_buses field Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 08/15] qmp: Add 'supported-device-types' field to 'query-machines' Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 09/15] pci: Introduce INTERFACE_PCIE_DEVICE interface name Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 10/15] pc: Initialize default bus lists Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 11/15] s390x: " Eduardo Habkost
2016-12-05 15:24   ` David Hildenbrand
2016-12-05 16:03     ` Cornelia Huck
2016-12-05 16:38       ` Eduardo Habkost
2016-11-22  1:12 ` [Qemu-arm] [RFC 12/15] arm: " Eduardo Habkost
2016-11-22  1:12   ` [Qemu-devel] " Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 13/15] mips: " Eduardo Habkost
2016-11-22  1:12 ` [Qemu-devel] [RFC 14/15] ppc: " Eduardo Habkost
2016-11-23  3:42   ` Alexey Kardashevskiy
2016-11-22  1:12 ` [Qemu-devel] [RFC 15/15] qdev: Add device_class_set_bus_type() function Eduardo Habkost
2016-11-22  1:34 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' no-reply
2016-11-22  1:36 ` no-reply
2016-11-22  8:18 ` David Hildenbrand
2016-11-22 13:09   ` Eduardo Habkost
2016-11-22 22:34 ` Eduardo Habkost
2016-11-23 17:10   ` [Qemu-arm] -nodefaults and available buses (was Re: [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines') Eduardo Habkost
2016-11-23 17:10     ` [Qemu-devel] -nodefaults and available buses (was " Eduardo Habkost
2016-11-23 17:10     ` Eduardo Habkost
2016-11-24  1:51     ` [Qemu-arm] -nodefaults and available buses (was Re: [Qemu-devel] " David Gibson
2016-11-24  1:51       ` [Qemu-devel] -nodefaults and available buses (was " David Gibson
2016-11-24  1:51       ` David Gibson
2016-11-24 16:30       ` Cornelia Huck
2016-11-24 16:30         ` Cornelia Huck
2016-11-24 17:42         ` [Qemu-arm] " Eduardo Habkost
2016-11-24 17:42           ` Eduardo Habkost
2016-11-24 13:39     ` Markus Armbruster [this message]
2016-11-24 13:39       ` Markus Armbruster
2016-11-23 16:43 ` [Qemu-devel] [RFC 00/15] qmp: Report supported device types on 'query-machines' Marcel Apfelbaum
2016-11-23 17:35   ` Eduardo Habkost
2016-11-24  9:34     ` Marcel Apfelbaum
2016-11-24 13:34     ` Markus Armbruster
2016-11-24 14:12       ` Eduardo Habkost
2016-11-24 14:55         ` Markus Armbruster
2016-11-24 14:22       ` Marcel Apfelbaum
2016-11-24 15:41         ` Markus Armbruster
2016-11-24 16:31           ` Marcel Apfelbaum
2016-11-25  8:03             ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87oa15dmjc.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=abologna@redhat.com \
    --cc=aik@ozlabs.ru \
    --cc=alex.williamson@redhat.com \
    --cc=atar4qemu@gmail.com \
    --cc=b.galvani@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=ehabkost@redhat.com \
    --cc=groug@kaod.org \
    --cc=laine@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=marcel@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=proljc@gmail.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.