qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Gross <jgross@suse.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Marcel Apfelbaum <marcel@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Laszlo Ersek <lersek@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [RFC 1/4] [UNTESTED] xen: Don't force has_dynamic_sysbus on machine class
Date: Fri, 24 Mar 2017 14:59:41 +0100	[thread overview]
Message-ID: <0d2ad0a3-dbc4-afed-c11d-071f5e8d13f2@suse.com> (raw)
In-Reply-To: <20170324135057.GD28530@thinpad.lan.raisama.net>

On 24/03/17 14:50, Eduardo Habkost wrote:
> On Fri, Mar 24, 2017 at 01:27:31PM +0100, Juergen Gross wrote:
>> On 24/03/17 12:10, Eduardo Habkost wrote:
>>> On Fri, Mar 24, 2017 at 11:24:31AM +0100, Juergen Gross wrote:
>>>> On 24/03/17 11:09, Peter Maydell wrote:
>>>>> On 24 March 2017 at 08:23, Juergen Gross <jgross@suse.com> wrote:
>>>>>> On 23/03/17 22:28, Eduardo Habkost wrote:
>>>>>>> The xen-backend devices created by the Xen code are not supposed
>>>>>>> to be treated as dynamic sysbus devices. This is an attempt to
>>>>>>> change that and see what happens, but I couldn't test it because
>>>>>>> I don't have a Xen host set up.
>>>>>>>
>>>>>>> If this patch breaks anything, this means we have a bug in
>>>>>>> foreach_dynamic_sysbus_device(), which is supposed to return only
>>>>>>> devices created using -device.
>>>>>>>
>>>>>>> The original code that sets has_dynamic_sysbus was added by
>>>>>>> commit 3a6c9172ac5951e6dac2b3f6cbce3cfccdec5894, but I don't see
>>>>>>> any comment explaining why it was necessary.
>>>>>>
>>>>>> xen-backend devices are created via qmp commands when attaching new
>>>>>> pv-devices to a domain. They can be dynamically removed, too. Setting
>>>>>> has_dynamic_sysbus was necessary to support this feature.
>>>>>
>>>>> This seems like it ought to be handled by marking the xen-backend
>>>>> devices as being ok-to-dynamically-create somehow, not by marking
>>>>> the machine as supporting dynamic-sysbus (which it doesn't).
>>>>> Maybe we don't have the necessary support code to do that though?
>>>>
>>>> When writing the patches I couldn't find a way to do it differently.
>>>> OTOH I'm not so deep in qemu internals I'd be able to add the needed
>>>> support.
>>>>
>>>> I'd be happy to test any patch, though.
>>>
>>> If xen-backend devices are created via QMP commands, then
>>> has_dynamic_sysbus is (currently) really needed, although I would
>>> have preferred to set it on all x86 machines instead of changing
>>> MachineClass::has_dynamic_sysbus outside class_init.
>>>
>>> But with the new whitelist implemented by this series, we could
>>> simply include xen-backend in the whitelist for the machines that
>>> can be used with Xen, and get rid of xen_set_dynamic_sysbus().
>>>
>>> I assume plugging/unplugging xen-backend devices apply to both
>>> xen{pv,fv} and pc,accel=xen, right? Do we need to make it work
>>> with "-machine none,accel=xen" and "-machine isapc" too?
>>
>> AFAIK -xenpv, -xenfv and -pc,accel=xen are the only machine types
>> to support. Wouldn't it make sense to do the whitelisting in
>> xen_be_register_common() in spite of setting has_dynamic_sysbus?
> 
> It would, but that would mean we would make the whitelisting
> mechanism more complex: in addition to the static
> per-machine-class whitelist, we would need a runtime whitelist.
> 
> This would make the interface for querying available/supported
> device types more complex and messier, and I would like to avoid
> that.
> 

Okay, understood. And I suppose you don't want to add the Xen
devices to the per-machine-class whitelist (after all my patch
did the same with the has_dynamic_sysbus flag) on demand.

Either way is fine with me.


Juergen

  reply	other threads:[~2017-03-24 13:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-23 21:28 [Qemu-devel] [RFC 0/4] Replace has_dynamic_sysbus with device type whitelist Eduardo Habkost
2017-03-23 21:28 ` [Qemu-devel] [RFC 1/4] [UNTESTED] xen: Don't force has_dynamic_sysbus on machine class Eduardo Habkost
2017-03-24  8:23   ` Juergen Gross
2017-03-24 10:09     ` Peter Maydell
2017-03-24 10:24       ` Juergen Gross
2017-03-24 11:10         ` Eduardo Habkost
2017-03-24 12:27           ` Juergen Gross
2017-03-24 13:50             ` Eduardo Habkost
2017-03-24 13:59               ` Juergen Gross [this message]
2017-03-24 10:32       ` Thomas Huth
2017-03-23 21:28 ` [Qemu-devel] [RFC 2/4] machine: Replace has_dynamic_sysbus with a whitelist Eduardo Habkost
2017-03-23 21:28 ` [Qemu-devel] [RFC 3/4] q35: Remove ioapic devices from sysbus whitelist Eduardo Habkost
2017-03-23 21:28 ` [Qemu-devel] [RFC 4/4] q35: Remove fw_cfg* " Eduardo Habkost
2017-03-24  8:27 ` [Qemu-devel] [RFC 0/4] Replace has_dynamic_sysbus with device type whitelist Juergen Gross

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=0d2ad0a3-dbc4-afed-c11d-071f5e8d13f2@suse.com \
    --to=jgross@suse.com \
    --cc=armbru@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=lersek@redhat.com \
    --cc=marcel@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sstabellini@kernel.org \
    --cc=thuth@redhat.com \
    /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).