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
