On Wed, Apr 12, 2017 at 05:18:51PM +0200, Markus Armbruster wrote: > Roman Kagan <rka...@virtuozzo.com> writes: > > 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.
I thought VMBus looked similar to an ISA or PCI bus in its relation to the system, and those bridges were TYPE_SYS_BUS_DEVICE. If it's subclassed directly from TYPE_DEVICE how is it connected to the rest of the QOM tree? > > 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. VMBus can't be hot-plugged into the system. Besides, there can be no more than one VMBus in the system, so multiple -device vmbus-bridge options would not be allowed; I thought this semantics was clearer with a machine option. > I'd be tempted to leave old i400FX rot in peace, but your use case may > not allow that. It doesn't ;) Besides, we've had no specal cases for i440fx vs q35 in our VMBus code so far, so I don't see any reason to not to support both. Thanks, Roman.
