I found no changes since the CRD nor a discussion on the ML of qemu or libvirt.
There are the backported fixes that add taa-no and pschange-mc-no to qemu - but nothing touches hle/rtm yet.
But that is a feature that will be in qemu >4.1 and newer libvirt, so look towards Ubuntu 20.04 and UCA derived from that for this feature.
It seems way too big and invasive for an SRU.
But even if you had that, you'd either have
a) unversioned type without consistency (might change on update, which isn't what you want either)
b) versioned types which stay static behave exactly as what we have now
@security - where there discussions about how to handle these feature losses in the "closed circle" around the TSX/TAA bug?
I found no changes since the CRD nor a discussion on the ML of qemu or libvirt.
There are the backported fixes that add taa-no and pschange-mc-no to qemu - but nothing touches hle/rtm yet.
The general answer of of the virt stack avoiding type proliferation are versioned CPU models. /git.qemu. org/?p= qemu.git; a=commit; h=aa5b969287125 d1924d74648b378 d4abba544465 /git.qemu. org/?p= qemu.git; a=commit; h=d86a708815c3b ec0b934760e6bda b7eb647087b8
=> https:/
=> https:/
But that is a feature that will be in qemu >4.1 and newer libvirt, so look towards Ubuntu 20.04 and UCA derived from that for this feature.
It seems way too big and invasive for an SRU.
But even if you had that, you'd either have
a) unversioned type without consistency (might change on update, which isn't what you want either)
b) versioned types which stay static behave exactly as what we have now
@security - where there discussions about how to handle these feature losses in the "closed circle" around the TSX/TAA bug?