Changelog:
 - mention the bug "once" not on each patch line. Not only not necesary, some tools get driven 
   nuts by that.
 - the upstream references are great to have in the patch header, but somewhat overdose in the 
   changelog
Example:
   3   * {Ice,Cascade}Lake CPUs + IA32_ARCH_CAPABILITIES support.                     
   4     Needed patches are in d/p/u/lp1828495-:                                      
   5     - 0001-guidance-cpu-models.patch (LP: #1828495):                             
   6       docs: add guidance on configuring CPU models for x86                       
   7       (upstream: 2544e9e4aa2b, desc: v3.0.0-151-g2544e9e4aa)                     
   8     - 0002-msr-new-msr-indices.patch (LP: #1828495):  
Better:
   3   * {Ice,Cascade}Lake CPUs + IA32_ARCH_CAPABILITIES support.                     
         (LP: #1828495)
   4     Needed patches are in d/p/u/lp1828495-:                                      
   5     - 0001-guidance-cpu-models.patch :                             
   6       docs: add guidance on configuring CPU models for x86                       
   8     - 0002-msr-new-msr-indices.patch:  

Could you fix the above across all of your new entry in debian/changelog please?

#1 header seems right now - thanks
  - yet I have not seen this in the commits
   https://salsa.debian.org/qemu-team/qemu/commit/2a17895ee2f9a4a78959edde7caccf77693679d4

#2 - #4  - ok

#5 I see you now left it as-is in favor of applying the real upstream change later on in the new #14/#15 - thanks.

#6 - ok - full header is closer to what upstream has, I found no backport issue, header good now

#7 - ok

#8 - I need to double check on that backport.
     Nothing found on the first pass, maybe checking again later ..

#9 - #12 - ok

#13 - ok for itself.
I double checked if we need https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg00074.html - but #7-#9 are exactly that - so ok

#14 - ok

I'm somewhat torn on how to best handle
b0a19803 i386: Update stepping of Cascadelake-Server
  -> we certainly have no pc_compat_3_1
  -> but what is the better fallback than just not adding it?
ecb85fe48cacb2f8740186e81f2f38a2e02bd963
  -> also setting pc_compat_3_1
  -> should we add that in a modified way and if so how to best do so?

=> Both changes to pc_compat_3_1 mean that on anything 3.1 and early MPX is on
So if you run (even on a newer qemu) such a type and get it from an earlier machine then it would e.g. have MPX on even it was dropped.
I think the right way to do this is to add all these changes that were done to pc_compat_3_1 in the upstream patches to the respective newest types of the release.
Because we change the code with the patches, and that means we'd otherwise change behavior.
Only >3.1 is it ok to really have MPX off by default.

That would mean we move those changes to
Bionic - pc_compat_2_11
Cosmic - pc_compat_2_12
Disco - we keep 3.1 as that is Disco atm.

That would ensure that the type doesn't change until a release post >=4.x
And even on a migration between those the old Bionic qemu would have MPX off (a 2.11 type) and the receiving qemu would know that (it knows all <4.0 are that way).

TODO:
- add ecb85fe48cacb2f8740186e81f2f38a2e02bd963 to the patches that we add for this
- do not drop the changes to pc_compat_3_1 but instead move it to the most recent compat of the qemu versions used
  - 4c257911dcc7 / #15
  - b0a1980384fc / #16



In general I like the backport notes, that is just how I do it on complex cases to remember the "why" on particular changes.
Fully optionally, an optimization might be e.g. where you say
    * positional changes due to missing upstream patch:                          
      e13713db5b60 ("KVM: x86: Add support for save/load MSR_SMI_COUNT") 
To add a line like:
      upstream released in v2.12.0
For the rebases later that makes it even easier.