From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Cc: "Peter Crosthwaite" <peter.crosthwaite@xilinx.com>,
"Nikunj A Dadhania" <nikunj@linux.vnet.ibm.com>,
qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
"Anthony Liguori" <aliguori@amazon.com>,
"Paul Mackerras" <paulus@samba.org>,
"Hervé Poussineau" <hpoussin@reactos.org>
Subject: Re: [Qemu-devel] [PATCH 2/5] machine: introduce get_fw_dev_path() callback
Date: Wed, 11 Dec 2013 16:20:34 +1100 [thread overview]
Message-ID: <52A7F622.4040203@ozlabs.ru> (raw)
In-Reply-To: <529DF195.3090107@redhat.com>
On 12/04/2013 01:58 AM, Paolo Bonzini wrote:
> Il 03/12/2013 15:35, Andreas Färber ha scritto:
>> Am 03.12.2013 15:00, schrieb Paolo Bonzini:
>>> Il 03/12/2013 14:44, Andreas Färber ha scritto:
>>>>>>
>>>>>> You can check "if (current_machine &&
>>>>>> current_machine->get_fw_dev_path)", and move current_machine from vl.c
>>>>>> to hw/qdev/core.c.
>>>> Please don't encourage moving random stuff into "core" device code.
>>>>
>>>> If needed, we can easily add a machine.c, but that should remain
>>>> softmmu-only.
>>>
>>> Another solution would be to:
>>>
>>> (1) add an interface which contains "get_fw_dev_path". When
>>> qdev_get_fw_dev_path is called, walk the QOM tree until an object that
>>> implements the interface is found. If none is found, call the bus
>>> implementation as usual.
>>>
>>> (2) in vl.c, add a way for current_machine to override the /machine
>>> object. A 100%-QOMified machine indeed could put a SOC-like Device there.
>>>
>>> (3) for spapr, define the machine object to something that implements
>>> said interface.
>>>
>>> It seemed a bit complicated for this particular problem, but I cannot
>>> say it's overengineered.
>>>
>>> More aspects of the configuration could be moved to the new interface
>>> over time, for example compat properties.
>>
>> I remember Hervé running into problems with interfaces and ppc -cpu ?
>> (or -cpu host?), which does an object_class_foreach(), in the middle of
>> which QOM interfaces tried registering new types, leading to a GLib
>> assertion. Anthony never replied to that patch despite repeated pings,
>> so the issue is likely still unresolved.
>>
>> http://patchwork.ozlabs.org/patch/241072/ (proposed workaround)
>> http://patchwork.ozlabs.org/patch/241504/ (test case)
>> http://patchwork.ozlabs.org/patch/241073/ (actual interface attempt)
>
> Well, let's fix it. Thanks for the test case.
Any progress on this?
I am asking since the patchset about bootindex you gave me yesterday prints
"(process:38896): GLib-CRITICAL **: g_hash_table_foreach: assertion
`version == hash_table->version' failed" which I "fixed" by moving the
machine object creation chunk before kvm_init() in vl.c.
btw what do I do with that patchset now? I works for me (except the issue
above), do I have to repost it again? Thanks.
--
Alexey
next prev parent reply other threads:[~2013-12-11 5:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 7:27 [Qemu-devel] [RFC PATCH 0/5] spapr: support bootindex Alexey Kardashevskiy
2013-11-25 7:27 ` [Qemu-devel] [PATCH 1/5] boot: extend get_boot_devices_list() to ignore suffixes Alexey Kardashevskiy
2013-11-25 7:27 ` [Qemu-devel] [PATCH 2/5] machine: introduce get_fw_dev_path() callback Alexey Kardashevskiy
2013-11-26 4:55 ` Alexey Kardashevskiy
2013-12-03 3:52 ` Alexey Kardashevskiy
2013-12-03 9:11 ` Markus Armbruster
2013-12-03 9:32 ` Alexey Kardashevskiy
2013-12-03 9:41 ` Paolo Bonzini
2013-12-03 13:41 ` Andreas Färber
2013-12-03 9:37 ` Paolo Bonzini
2013-12-03 13:44 ` Andreas Färber
2013-12-03 14:00 ` Paolo Bonzini
2013-12-03 14:35 ` Andreas Färber
2013-12-03 14:58 ` Paolo Bonzini
2013-12-11 5:20 ` Alexey Kardashevskiy [this message]
2013-12-11 7:47 ` Paolo Bonzini
2013-12-11 7:59 ` Alexey Kardashevskiy
2013-12-11 8:38 ` Alexey Kardashevskiy
2013-12-10 7:34 ` Alexey Kardashevskiy
2013-11-25 7:27 ` [Qemu-devel] [PATCH 3/5] spapr-llan: add to boot device list Alexey Kardashevskiy
2013-11-25 7:27 ` [Qemu-devel] [PATCH 4/5] spapr-vio: fix firmware names Alexey Kardashevskiy
2013-11-25 7:27 ` [Qemu-devel] [PATCH 5/5] spapr: define get_fw_dev_path() callback Alexey Kardashevskiy
2013-11-26 4:05 ` [Qemu-devel] [PATCH v2] " Alexey Kardashevskiy
2013-11-26 4:07 ` [PATCH] boot: enable support for bootindex Alexey Kardashevskiy
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=52A7F622.4040203@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=hpoussin@reactos.org \
--cc=nikunj@linux.vnet.ibm.com \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--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.