# DOCUMENTING IRC DISCUSSION:


08:54 <rafaeldtinoco> cpaelzer: with your suggestion, we would have to up PC_COMPAT every release by putting the same value in the new one 
08:54 <rafaeldtinoco> no ?

08:56 <cpaelzer> no
08:57 <cpaelzer> we'd change the default that gets added
08:57 <cpaelzer> since out active code is "before" compat 3.1

08:57 <rafaeldtinoco> cpaelzer: alright, lets do one example together
08:58 <rafaeldtinoco> just to make sure we covered it all

08:58 <cpaelzer> may I take the easiest one :-)
08:58 <cpaelzer> :-P
08:58 <cpaelzer> b0a1980384fc265d91de7e09aa5fe531a69e6288
08:58 <cpaelzer> the upstream cahnge will make it be stepping 6 AFTER 3.1
08:58 <cpaelzer> since we are before we will NOT change it to 6
08:58 <cpaelzer> which means we will drop the patch completely

08:59 <rafaeldtinoco> but cascadelake wasnt even supported in 2_10/2_11
08:59 <rafaeldtinoco> thats the point of backporting its support
08:59 <rafaeldtinoco> and without stepping
08:59 <rafaeldtinoco> the features arent even supported
08:59 <rafaeldtinoco> (the ones we are adding)

08:59 <cpaelzer> sure, but it still defines it like that
08:59 <cpaelzer> so a qemu 4.0 would expect an old Cascadelake-Server to be stepping 5
08:59 <cpaelzer> and that is what we will make it by -not- adding this patch

08:59 <rafaeldtinoco> cpaelzer: without IA32 feature
08:59 <rafaeldtinoco> but we will have it
09:00 <rafaeldtinoco> if you dont bump the stepping
09:00 <rafaeldtinoco> feature is not enabled (for cascade model)
09:00 <rafaeldtinoco> the extra mitigation tags
09:00 <rafaeldtinoco> (ARCH_CAPABILITIES.)
09:01 <rafaeldtinoco> that is what tricked me ^

09:01 <cpaelzer> just now read the spec on that stepping
09:01 <cpaelzer> yeah this is silly
09:01 <cpaelzer> we need a special solution for the stepping then
09:01 <cpaelzer> which is ok
09:02 <cpaelzer> ok, since the type never existed lets add it with stepping 6 into all our qemu's
09:02 <cpaelzer> what we need to do then is when I merge qemu 4.0 or later (and essentially forever)
09:02 <cpaelzer> to REMOVE the line that declares pre 3.1 cascade lake as stepping 5
09:03 <cpaelzer> rafaeldtinoco: I have added a todo to the trello card for the virt-stack merges
09:05 <cpaelzer> hw/i386/pc.cso for the SRU-backports of b0a19803 we'd want the change to target/i386/cpu.c but not the one to hw/i386/pc.c
09:06 <cpaelzer> you'd need to slightly rework patch #17 for that
09:07 <cpaelzer> keeping the technical dept (in the form of delta to be kept forever) low, can we just not add ecb85fe48cacb2f8740186e81f2f38a2e02bd963 then (patch #15)

09:07 <rafaeldtinoco> cpaelzer: perfect. that is much better

09:07 <cpaelzer> at lesat that seems to follow my thought
09:08 <cpaelzer> by not adding #15 we will NOT switch MPX off
09:08 <cpaelzer> and that means it will still be on

09:08 <rafaeldtinoco> cpaelzer: it makes sense

09:08 <cpaelzer> qemu >=4.0 will consider anything <=3.1 to have MPX on

09:08 <rafaeldtinoco> i thought similar (dragging the change for upper versions)
09:08 <rafaeldtinoco> but not having it and removing the delta
09:08 <rafaeldtinoco> is better to maintain
09:08 <rafaeldtinoco> alright, what about mpx ?

09:08 <cpaelzer> so my thought was righ tin general, but just on patch #17 killed by that silly stepping defining some inherent features
09:09 <cpaelzer> #15 that I mentioned is MPX
09:09 <cpaelzer> or has that a hidden "has to be there" mission as well?

09:09 <rafaeldtinoco> ah ok
09:09 <rafaeldtinoco> lemme check
09:09 <rafaeldtinoco> nope, its just being phased out by intel

09:10 <cpaelzer> rafaeldtinoco: Summary: rework #17 (stepping) to not change compat; add a todo for the 4.0 merge (done), drop patch#15 (MPX)
09:10 <cpaelzer> ^^ ack?

09:10 <rafaeldtinoco> IF someone is running QEMU on Bionic, in a {Sky,Cascade}Lake CPU, has MPX on by default, a possibly different (than Ubuntu) guest OS (other Linux distro ?) AND is running a object containing instructions of that ABI extension (GCC in between 5 and 9 compiled objects and kernel 3.19 - 4.20) WHILE doing a live migration from this QEMU version to higher one, then.. this person would face a bug :o).
09:10 <rafaeldtinoco> that was my comment on msx  ^
09:11 <rafaeldtinoco> if you're ok with that "corner case"
09:11 <rafaeldtinoco> with all planets aligned for a bug to happen

09:11 <cpaelzer> it is on as of today
09:11 <cpaelzer> if upstream considered it a bug more important than compatibility, they would have changed it in general
09:11 <cpaelzer> but they only did >=4.0
09:11 <cpaelzer> so I'd follow that

09:11 <rafaeldtinoco> makes sense
09:11 <rafaeldtinoco> so your summary is ok
09:12 <rafaeldtinoco> will provide the changes
09:12 <rafaeldtinoco> ;) tks

09:12 <cpaelzer> the one MPX I wonder, is that disabled in every other CPU type but these new named ones ...?

09:12 <rafaeldtinoco> i think the new models are being deprecated
09:12 <rafaeldtinoco> but feature is still there
09:13 <rafaeldtinoco> or something like it (judging by the commit messages)

09:13 <cpaelzer> as I thought it is on as of today
09:13 <cpaelzer> Skylake-Client Skylake-Server have CPUID_7_0_EBX_MPX set

09:13 <rafaeldtinoco> Even though KVM will have special code
09:13 <rafaeldtinoco> +to support MPX after the kernel proper stops enabling it in XCR0,

09:14 <cpaelzer> and they didn#t even change those in ecb85fe48cacb2f8740186e81f2f38a2e02bd963
09:14 <cpaelzer> ... want to deprecate that in a few years ...

09:14 <rafaeldtinoco> yep
09:14 <rafaeldtinoco> lets kepe it

09:14 <cpaelzer> I think we are good with the plan as sumamrized above

09:14 <rafaeldtinoco> specially since this is a backport
09:14 <rafaeldtinoco> ok
09:14 <rafaeldtinoco> good =)