On 5/6/21 8:51 AM, Daniel P. Berrangé wrote:
> I see. So it sounds like the way forward for libvirt is that it
will
> need to essentially duplicate the SEV-related QMP message types into its
> own protocol since expecting the client to understand QMP discloses the
> fact that the underlying hypervisor is QEMU.
I wouldn't say duplicate the SEV QMP messages, as I wouldn't assume that
there's a direct 1:1 mapping between what libvirt exposes and what QMP
exposes. There will be some mapping, but it could well be M:N, since
libvirt aims to express things as higher level concepts that stand a
better chance of being cross-hypervisor applicable [1], rather than
just 1:1 duplicating QEMU.
The SEV QMP messages are just JSON representations of the SEV firmware
data structures. The client requires exactly those data structures and
nothing more; so it is almost certainly and unavoidably going to be a
1:1 cut and paste job. So to be clear, it's not duplicating QEMU, just
unpacking from QMP and dropping the data structures into whatever
message type libvirt exposes.
Connor