> On Jul 15, 2020, at 3:39 PM, Krish Sadhukhan <krish.sadhukhan@xxxxxxxxxx> wrote: > > > On 7/15/20 3:27 PM, Nadav Amit wrote: >>> On Jul 15, 2020, at 3:21 PM, Krish Sadhukhan <krish.sadhukhan@xxxxxxxxxx> wrote: >>> >>> >>> On 7/13/20 4:30 PM, Nadav Amit wrote: >>>>> On Jul 13, 2020, at 4:17 PM, Krish Sadhukhan <krish.sadhukhan@xxxxxxxxxx> wrote: >> [snip] >> >>>>> I am just saying that the APM language "should be cleared to 0" is misleading if the processor doesn't enforce it. >>>> Just to ensure I am clear - I am not blaming you in any way. I also found >>>> the phrasing confusing. >>>> >>>> Having said that, if you (or anyone else) reintroduces “positive” tests, in >>>> which the VM CR3 is modified to ensure VM-entry succeeds when the reserved >>>> non-MBZ bits are set, please ensure the tests fails gracefully. The >>>> non-long-mode CR3 tests crashed since the VM page-tables were incompatible >>>> with the paging mode. >>>> >>>> In other words, instead of setting a VMMCALL instruction in the VM to trap >>>> immediately after entry, consider clearing the present-bits in the high >>>> levels of the NPT; or injecting some exception that would trigger exit >>>> during vectoring or something like that. >>>> >>>> P.S.: If it wasn’t clear, I am not going to fix KVM itself for some obvious >>>> reasons. >>> I think since the APM is not clear, re-adding any test that tests those bits, is like adding a test with "undefined behavior" to me. >>> >>> >>> Paolo, Should I send a KVM patch to remove checks for those non-MBZ reserved bits ? >> Which non-MBZ reserved bits (other than those that I addressed) do you refer >> to? > I am referring to, > > "[PATCH 2/3 v4] KVM: nSVM: Check that MBZ bits in CR3 and CR4 are not set on vmrun of nested guests" > > in which I added the following: > > > +#define MSR_CR3_LEGACY_RESERVED_MASK 0xfe7U > +#define MSR_CR3_LEGACY_PAE_RESERVED_MASK 0x7U > +#define MSR_CR3_LONG_RESERVED_MASK 0xfff0000000000fe7U Oh, you refer to KVM, not kvm-unit-tests... That’s out of my scope ;-)
