Peter Krempa <pkre...@redhat.com> writes: > On Wed, Dec 11, 2019 at 12:32:10 +0000, Daniel Berrange wrote: >> On Wed, Dec 11, 2019 at 01:24:17PM +0100, Kevin Wolf wrote: >> > Am 11.12.2019 um 11:51 hat Peter Krempa geschrieben: >> > > On Wed, Dec 11, 2019 at 11:14:39 +0100, Kevin Wolf wrote: > > [...] > >> > > Well, in some specific cases we could detect the node names >> > > auto-assigned by qemu and use them instead of paths, but in my opinion >> > > it's not worth the effort and extra code. >> > >> > Well, the question is what to do on the QEMU side then. Deprecation >> > should mean that we have a plan for removing the feature. If we're >> > planning to keep the feature indefinitely because libvirt needs it, we >> > might want to consider removing the deprecation notice. >> >> Ideally libvirt would stop using -drive entirely, as I hate the idea of >> having to keep this around indefinitely in libvirt too. This needs QEMU >> to close the last gaps wrt SD cards > > Yes and also give us guidance how to convert it. Looking at the code > didn't help. There's a plethora of controllers and options to configure > without clear indication what is default behaviour expected.
Similar situation as for if=pflash. That one we addressed just for "tier 1" machine types: i386 pc-*, arm virt-*. Would addressing if=sd just for these machines suffice? Addressing if=pflash and if=sd for all machines looks is beyond my capacity. For a more detailed analysis, see my "Review of onboard block device configuration with -drive", Message-ID: <87fti1i0oi....@dusky.pond.sub.org>. Relevant parts: The interface types are: [...] * if=pflash Many machines have onboard pflash devices. They recognize bus=0,unit=U where 0 <= U < number of such onboard devices. ARM machine sbsa-ref, virt, i386 machines pc*, isapc, xenfv, Risc-V machine virt provide machine properties for connecting backends to their onboard pflash devices. For the other machines, -drive is still the only way to connect backends. PPC machines pseries* create spapr-nvram devices instead. It can be created with -device instead. SPARC machine niagara creates a memory region instead *boggle*. -drive is the only way to configure that. Other machines create the onboard pflash device only when the corresponing drive is present. Since pflash devices are not pluggable, -drive is the only way to create them. [...] * if=sd Many machines have onboard sd-card devices. They recognize bus=0,unit=U where 0 <= U < number of such onboard devices. -drive is the only way to connect backends. [...] Summary [...] * if=pflash, if=mtd and if=sd are blocked by the "no way to connect backends to onboard devices" issue, and the "no way to create the device" issue. We solved them for if=pflash with some boards. Many more remain. > Trying to convert it blindly would end up worse than just ditching > support for sdcards altogehter. Tempting, isn't it?