Comment 19 for bug 1922907

I was now able to get hold of a cascade lake chip (there are many types) that was formerly already correctly recognized and working. In this case I can confirm that the change didn't have any negative impact.

It was before&after:
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>Cascadelake-Server</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='vmx'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='pku'/>
      <feature policy='require' name='md-clear'/>
      <feature policy='require' name='stibp'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='xsaves'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='rdctl-no'/>
      <feature policy='require' name='ibrs-all'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='require' name='mds-no'/>
      <feature policy='require' name='pschange-mc-no'/>
      <feature policy='disable' name='hle'/>
      <feature policy='disable' name='rtm'/>
    </mode>

And also the usability of that chip didn't change and stayed
      <model usable='yes'>Cascadelake-Server-noTSX</model>

So far so good, waiting for the upload to be accepted into Hirsute as zero day SRU - but stalled by the release.