[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] vmbus bridge: machine property or device?
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] vmbus bridge: machine property or device? |
Date: |
Wed, 12 Apr 2017 17:07:20 -0300 |
User-agent: |
Mutt/1.7.1 (2016-10-04) |
On Wed, Apr 12, 2017 at 05:18:51PM +0200, Markus Armbruster wrote:
> Cc'ing a few more people who might have a reasoned opinion.
>
> Roman Kagan <address@hidden> writes:
>
> > While hammering out the VMBus / storage series, we've been struggling to
> > figure out the best practices solution to the following problem:
> >
> > VMBus is provided by a vmbus bridge; it appears the most natural to have
> > it subclassed from SysBusDevice. There can only be one VMBus in the
> > VM.
>
> TYPE_DEVICE unless you actually need something TYPE_SYS_BUS_DEVICE
> provides.
>
> > Now the question is how to add it to the system:
> >
> > 1) with a boolean machine property "vmbus" that would trigger the
> > creation of the VMBus bridge; its class would have
> > ->cannot_instantiate_with_device_add_yet = true
>
> This makes it an optional onboard device. Similar ones exist already,
> e.g. various optional onboard USB host controllers controlled by machine
> property "usb".
>
> > 2) with a regular -device option; this would require setting
> > ->has_dynamic_sysbus = true for i440fx machines (q35 already have it)
>
> This makes it a pluggable sysbus device.
>
> I'd be tempted to leave old i400FX rot in peace, but your use case may
> not allow that.
I have sent a RFC some time ago that replaces the all-or-nothing
has_dynamic_sysbus flag with an explicit sysbus device whitelist,
so i440fx wouldn't be a big problem. But as you noted above, if
you don't need TYPE_SYS_BUS_DEVIC, you can just use TYPE_DEVICE.
>
> >
> > 3) anything else
> >
> >
> > So far we went with 1) but since it's essentially the API the management
> > layer would have to use we'd like to get it right from the beginning.
>
> Asking for advice here is a good idea.
>
> Anyone?
>
I would go with (2) instead of (1): it allows more flexibility in
case the device needs additional arguments, and will
automatically benefit from (present and future) mechanisms for
reporting available device-types and buses. Asking QEMU if
"-device FOO" is supported is easy and reliable; the mechanisms
for asking QEMU about supported "-machine" options are obscure
and probably not well-tested.
--
Eduardo
- [Qemu-devel] vmbus bridge: machine property or device?, Roman Kagan, 2017/04/11
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Markus Armbruster, 2017/04/12
- Re: [Qemu-devel] vmbus bridge: machine property or device?,
Eduardo Habkost <=
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Roman Kagan, 2017/04/13
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Eduardo Habkost, 2017/04/13
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Peter Maydell, 2017/04/13
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Eduardo Habkost, 2017/04/13
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Peter Maydell, 2017/04/13
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Roman Kagan, 2017/04/13
- Re: [Qemu-devel] vmbus bridge: machine property or device?, Roman Kagan, 2017/04/13
Re: [Qemu-devel] vmbus bridge: machine property or device?, Roman Kagan, 2017/04/13