On Tue, May 14, 2019 at 06:03:09PM +0200, Andrea Bolognani wrote: > I thought about it a bit more and perhaps the simplified design is > better after all. > > Whatever the interface looks like on the QEMU side, we're going to > want to offer libvirt users two options for configuring vector > lengths: listing all desired vector lengths explicitly (basically > sev-vl-map but more verbose and readable) and providing just the > biggest desired vector length (like in sev-max-vq). > > In the latter case, we'll want to expand the user-provided value > into an explicit list anyway in order to guarantee guest ABI > stability, and doing so when a single bitmap has been obtained via > QMP seems like it would be more manageable. > > Sorry for the flip-flop, but after all isn't this exactly what > upstream design discussion is supposed to be all about? :)
Yup, no problem. I'm actually liking the idea of the single map plus flags. We won't need two implementations (QEMU and libvirt), we'll only need one (libvirt). The QEMU QMP side will only need to state what should be implemented using the flags. Also, as we already agreed, we need TCG and KVM flags anyway, so we're already in flag land. > > [...] > > > If the size of the bitmap on the KVM side is 512 bits, why don't we > > > just make it that size on the QEMU side too from the start? > > > > I'd still only want to input 64-bits on the command line, otherwise > > we get into inputting arrays, which isn't easy. KVM's interface is > > meant for expansion, but it won't be using most of those bits for > > quite some time either. > > I'm probably missing something entirely obvious, but couldn't you > just have a single, possibly fairly massive (up to 128 hex digits if > I'm not mistaken) value on the command line and just work with that > one, no arrays necessary? > We could, and I like the idea. It just hadn't crossed my mind due to implementation tunnel vision. Thanks, drew
