On 6/22/20 1:01 PM, Paolo Bonzini wrote: > On 22/06/20 19:57, Tom Lendacky wrote: >>>> In bare-metal, there's no guarantee a CPU will report all the faults in a >>>> single PF error code. And because of race conditions, software can never >>>> rely on that behavior. Whenever the OS thinks it has cured an error, it >>>> must always be able to handle another #PF for the same access when it >>>> retries because another processor could have modified the PTE in the >>>> meantime. >>> I agree, but I don't understand the relation to this patch. Can you >>> explain? >> >> I guess I'm trying to understand why RSVD has to be reported to the guest >> on a #PF (vs an NPF) when there's no guarantee that it can receive that >> error code today even when guest MAXPHYADDR == host MAXPHYADDR. That would >> eliminate the need to trap #PF. > > That's an interesting observation! But do processors exist where either: > > 1) RSVD doesn't win over all other bits, assuming no race conditions There may not be any today, but, present bit aside (which is always checked), there is no architectural statement that says every error condition has to be checked and reported in a #PF error code. So software can't rely on RSVD being present when there are other errors present. That's why I'm saying I don't think trapping #PF just to check and report RSVD should be done. > > 2) A/D bits can be clobbered in a page table entry that has reserved > bits set? There is nothing we can do about this one. The APM documents this when using nested page tables. If the guest is using the same MAXPHYADDR as the host, then I'm pretty sure this doesn't happen, correct? So it's only when the guest is using something less than the host MAXPHYADDR that this occurs. I'm not arguing against injecting a #PF with the RSVD on an NPF where it's detected that bits are set above the guest MAXPHYADDR, just the #PF trapping. Thanks, Tom > > Running the x86/access.flat testcase from kvm-unit-tests on bare metal > suggests that all existing processors do neither of the above. > > In particular, the second would be a showstopper on AMD. > > Paolo >
