From: "Ján Tomko" <jtomko@redhat.com>
To: Alexander Graf <agraf@suse.de>, Eric Blake <eblake@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Michael Roth" <mdroth@linux.vnet.ibm.com>,
"Anthony Liguori" <aliguori@amazon.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] Should we have a 2.0-rc3 ?
Date: Thu, 10 Apr 2014 15:41:33 +0200 [thread overview]
Message-ID: <53469F8D.2040808@redhat.com> (raw)
In-Reply-To: <4FBBA28F-184E-45A4-A7B8-6F4ED4EFC205@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]
On 04/10/2014 02:46 PM, Alexander Graf wrote:
>
> On 10.04.2014, at 14:44, Eric Blake <eblake@redhat.com> wrote:
>
>> On 04/10/2014 05:17 AM, Peter Maydell wrote:
>>> So far I know of at least three fixes which should probably
>>> go into 2.0:
>>> * my fix for the configure stack-protector checks on MacOSX
>>> * MST's pull request updating the ACPI test blobs
>>> * MST says we need to update the hex files for ACPI too
>>> (otherwise you get a different ACPI blob depending on whether
>>> your build system had iasl or not, if I understand correctly)
>>>
>>> Are there any others?
>>
>> Yes. The libvirt team is a bit annoyed that the pci bus naming was
>> changed for PPC but not all architectures, but without a proper QMP
>> command to probe which naming scheme is in effect. We thought that the
>> naming scheme was going to be universally supplied for all arches, not
>> just PPC.
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg01533.html
>>
>> Is this something that can be quickly fixed (perhaps by reverting the
>> PPC patch until a more complete solution is ready), and if so, is it
>> worth doing for 2.0 proper, rather than waiting for 2.0.1?
>
> Which way works better for you? I'd be perfectly fine with reverting the patch. Libvirt is the only reason that path is there in the first place.
>
If I read the git history correctly, there were two patches changing pci bus
names for ppc in this release, not just one:
commit 1b8601b0ea0b91467561e0bbddd52a833e4b2b1a
Author: Alexey Kardashevskiy <aik@ozlabs.ru>
AuthorDate: 2014-03-06 14:11:00 +1100
Commit: Andreas Färber <afaerber@suse.de>
CommitDate: 2014-03-12 20:13:02 +0100
spapr-pci: Change the default PCI bus naming
Previously libvirt required the first/default PCI bus to have name "pci".
Since QEMU can support multiple buses now, libvirt wants "pci.0" now.
This removes custom bus name and lets QEMU make up default names.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Andreas Färber <afaerber@suse.de>
commit 8a0e11045d5f50d300e0ab1ba05f4c8217fb5dcb
Author: Alexander Graf <agraf@suse.de>
AuthorDate: 2013-12-04 12:42:32 +0100
Commit: Alexander Graf <agraf@suse.de>
CommitDate: 2013-12-20 01:58:01 +0100
PPC: Use default pci bus name for grackle and heathrow
There's no good reason to call our bus "pci" rather than let the default
bus name take over ("pci.0").
The big downside to calling it different from anyone else is that tools
that pass -device get confused. They are looking for a bus "pci.0" rather
than "pci".
To make life easier for everyone, let's just drop the name override.
Signed-off-by: Alexander Graf <agraf@suse.de>
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-04-10 13:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 11:17 [Qemu-devel] Should we have a 2.0-rc3 ? Peter Maydell
2014-04-10 11:24 ` Alexander Graf
2014-04-10 15:22 ` Michael S. Tsirkin
2014-04-10 11:49 ` Kevin Wolf
2014-04-10 12:44 ` Eric Blake
2014-04-10 12:46 ` Alexander Graf
2014-04-10 12:51 ` Eric Blake
2014-04-10 12:56 ` Alexander Graf
2014-04-10 13:41 ` Ján Tomko [this message]
2014-04-10 13:45 ` Alexander Graf
2014-04-10 15:02 ` Eric Blake
2014-04-10 15:27 ` Alexander Graf
2014-04-10 15:38 ` Eric Blake
2014-04-10 15:42 ` Alexander Graf
2014-04-11 8:01 ` Markus Armbruster
2014-04-11 8:37 ` Daniel P. Berrange
2014-04-10 15:26 ` Michael S. Tsirkin
2014-04-10 18:55 ` Cole Robinson
2014-04-10 21:30 ` Peter Maydell
2014-04-11 17:37 ` Peter Maydell
2014-04-11 22:55 ` Alexander Graf
2014-04-12 1:49 ` Paolo Bonzini
2014-04-12 8:48 ` Michael Tokarev
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=53469F8D.2040808@redhat.com \
--to=jtomko@redhat.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aliguori@amazon.com \
--cc=eblake@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).