[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] q35 and sysbus devices

From: Laszlo Ersek
Subject: Re: [Qemu-devel] q35 and sysbus devices
Date: Wed, 22 Mar 2017 21:46:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 03/22/17 21:31, Eduardo Habkost wrote:
> Hi,
> I am investigating the current status of has_dynamic_sysbus and
> sysbus device support on each of QEMU's machine types. The good
> news is that almost all has_dynamic_sysbus=1 machines have their
> own internal (often short) whitelist of supported sysbus device
> types, and automatically reject unsupported devices.
> ...except for q35.
> q35 currently accepts all sys-bus-device subtypes on "-device",
> and today this includes the following 23 devices:
> * allwinner-ahci
> * amd-iommu
> * cfi.pflash01
> * esp
> * fw_cfg_io
> * fw_cfg_mem
> * generic-sdhci
> * hpet
> * intel-iommu
> * ioapic
> * isabus-bridge
> * kvmclock
> * kvm-ioapic
> * kvmvapic
> * SUNW,fdtwo
> * sysbus-ahci
> * sysbus-fdc
> * sysbus-ohci
> * unimplemented-device
> * virtio-mmio
> * xen-backend
> * xen-sysdev
> My question is: do all those devices really make sense to be used
> with "-device" on q35?

I think fw_cfg_io and fw_cfg_mem should be board-only devices (no
-device switch).

Regarding cfi.pflash01, I think originally it would have been nice to
specify pflash chips with the modern (non-legacy) syntax, that is,
separate -drive if=none,file=... backend options combined with -device
cfi.pflash01,drive=... frontend options. However, that ship has sailed,
even libvirt uses -drive if=pflash for these, and given the purpose we
use pflash chips for, on Q35, I don't see much benefit in exposing
cfi.pflash01 with a naked -device *now*.

Re: virtio-mmio, I don't think that should be available on Q35 at all.

I can't comment on the rest.


> Should we make q35 validate dynamic sysbus
> devices against a whitelist, like the other has_dynamic_sysbus
> machines?
> I'm asking this because I will resume work on the
> "query-device-slots" command, which will report supported sysbus
> devices too. And I don't want the new command to report any
> devices that it shouldn't.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]