On Thu, Jul 28, 2022, Michael Roth wrote: > On Thu, Jul 28, 2022 at 02:56:50PM +0000, Sean Christopherson wrote: > > On Thu, Jul 28, 2022, Michael Roth wrote: > > Speaking of which, what prevents hardware (firmware?) from configuring the C-bit > > position to be bit 51 and thus preventing KVM from generating the reserved #NPF? > > I'm not sure if there's a way to change this: the related PPR documents > the CPUID 0x8000001F as read-only along with the expected value, but > it's not documented as 'fixed' so maybe there is some way. > > However in this case, just like with Milan the C-bit position actually > already is 51, but since for guests we rely on the value from > boot_cpu_data.x86_phys_bits, which is less than 51, any bits in-between > can be used to generate the RSVD bit in the exit field. Ya, I forgot to include the "and MAXPHYADDR >= 50" clause. > So more problematic would be if boot_cpu_data.x86_phys_bits could be set > to 51+, in which case we would silently break SEV-ES/SNP in a similar > manner. That should probably just print an error and disable SEV-ES, > similar to what should be done if mmio_caching is disabled in KVM > module. This is the scenario I'm curious about. It's mostly a future problem, so I guess I'm just wondering if there's a plan for making things work if/when this collision occurs.
