On Wed, Mar 1, 2017 at 10:56 PM Daniel P. Berrange <berra...@redhat.com> wrote:
> On Wed, Mar 01, 2017 at 06:32:19PM +0000, Marc-André Lureau wrote: > > Hi > > > > On Wed, Mar 1, 2017 at 10:20 PM Michael S. Tsirkin <m...@redhat.com> > wrote: > > > > > > > > > You're also tieing the code > > > > into the QEMU release cycle, again for no tangible benefit. > > > > > > No need for ABI stability would be the benefit. > > > > > > > We are talking about the control channel ABI (the data channel is using > TCG > > defined command streams afaict - don't remember what it is called) > > > > > > > > > > > Conceptually > > > > swtpm does not depend on, or require, QEMU to be useful - it can have > > > > other non-QEMU consumers - bundling with QEMU is not helpful there. > > > > > > Maybe it could but it isn't. > > > > > > > Right, it would be reasonable to have qemu provide it's own private > "swtpm" > > (linking with libtpms, doing most of the job), that way it wouldn't have > to > > rely on a stable ABI (as long as the process isn't shared across > different > > qemu versions, which should be quite easy to achieve) > > I think we need to expect to have a stable ABI no matter what. During > upgrade cycles, it is desirable to be able to upgrade the swtpm process > assocatied with a running VM. Whether this is done by restarting the > process & having QEMU reconnect, or by re-exec'ing swtpm and keeping the > FD open, you still end up with newer swtpm talking to an older QEMU. Or > I am not sure why this is required. You could require that both qemu & helper process are restarted in this case so they stay in sync, no? > conversely you might have setup swtpm processes to populate a number of > CUSE devices, and then later launch QEMU binaries to connect to them - at > I would rather avoid CUSE device with this private qemu helper process. > which point there's no guarantee the QEMU version hasn't been upgraded - > or the user could have requested a custom QEMU binary to virt-install, > etc. > The point is to have the qemu binary tight with the helper process. If they are incompatible, you broke your installation, it should fail to start. -- Marc-André Lureau
