On Fri, Jun 09, 2017 at 01:01:54AM +0200, Laszlo Ersek wrote: > On 06/08/17 21:55, Michael S. Tsirkin wrote: > > On Thu, Jun 08, 2017 at 09:48:53PM +0200, Gerd Hoffmann wrote: > >> Hi, > >> > >>> I really dislike negotiation being re-invented for each device. Do > >>> we > >>> need these tricks? Can we just do fw cfg with standard discovery? > >>> This ties in with my proposal to generalize smi features to > >>> generic ones. > >> > >> Device properties should be part of the device. > >> We should have done this with the smi too. > > > > What is part of the device and what isn't? It's all part > > of QEMU in the end. Adding probing for multiple devices > > will just add to number of exits and slow down guest boot. > > > > We do want to stick to emulating real devices if we can, no argument > > here - but this stuff is PV anyway - what do we gain by spreading it > > out? > > > >> A more standard way to handle this would be to add a vendor-specific > >> pci capability and place the register there. Not sure we have room for > >> that in the pci config space though. > >> > >> cheers, > >> Gerd > > > > We don't have room anywhere in PCI config space. Laszlo makes argument > > why it's safe for this device based on spec but it's anyone's guess > > whether current and future software will follow spec. In short, going > > anywhere near the emulated device has a potential to break some drivers. > > I'm fine using any QEMU facility that lets independent firmware modules > perform their feature detections / negotiations / lockdowns in arbitrary > order between each other. (Hopefully without extreme parsing requirements.)
How about adding etc/mch/features etc copying the smi stuff? Is this simple enough? We can worry about removing code duplication later. > What I can not sign up for is to develop a general QEMU infrastructure > for this (regardless of whether it is the fw_cfg bitmap stuff prevails, > or the PCI config space register / capability list). Either is complex > work, needing documentation too, the design has to be future proof. I'm > not experienced enough in QEMU to get it right reasonably soon > (everything is surprisingly complex and difficult in QEMU -- this has > been my experience over the years, and I still struggle with QOM every > single time), and I definitely do not have the capacity to take on a > QEMU feature of the suggested size. > > It's not lack of interest on my part, but lack of capacity. (Case in > point: it's ~1AM local time, and my laptop's uptime, which quite closely > approximates the hours I've actually spent working today, is ~15:30.) > The reason I keep submitting these little patches to qemu-devel is that > I figure everyone else is overloaded too, so I might as well try what > I'm capable of. But, we should be clear that that is not much, load-wise > and sophistication-wise. > > The alternative could have been that I'd clone > <https://bugzilla.redhat.com/show_bug.cgi?id=1447027> to qemu-kvm-rhev > (from OVMF), set up the cross-BZ dependencies correctly, wait until the > clone gets assigned to a seasoned QEMU developer, and once he or she > gets to work on it, we figure out the design together, and once he/she > writes the code for QEMU, I write the code for the firmware. > > I figured that sending a patch like the present one (having discussed it > preliminarily with Gerd and Paolo in the "[edk2] SMRAM sizes on large > hosts" thread) would be more efficient than waiting for a seasoned QEMU > developer. I didn't expect that my patch would be better than theirs. :) > The above kind of collaboration has certainly proved functional in the > past, it just takes a lot of time and coordination. > > Anyway, "Laszlo embarking on a QEMU infrastructure project that's liable > to take fifteen patch set iterations" is not an alternative, > unfortunately. I definitely don't intend to throw QEMU patches over the > fence; I know what drag that creates for maintainers. I intend to be > responsible for my QEMU patches. However -- or perhaps, "exactly because > of that"? -- I simply can't take on QEMU work that's larger than this > caliber. > > Sorry about the wall of text. > > Thanks, > Laszlo