> From: Peter Xu <pet...@redhat.com> > Sent: Monday, November 29, 2021 11:14 AM > > On Mon, Nov 29, 2021 at 10:28:42AM +0800, Jason Wang wrote: > > > > And in the future, it could be even more troublesome,e.g there's one > > day we found another bit that needs not to be checked. Maybe we should > > even remove all the rsvd bits checks? > > When a real hardware sees any of the reserved bits set, it'll bail out and > raise an error, right?
I think so. vtd spec has defined Non-zero reserved field error code against all the translation structures (root/context/pasid dir/pasid table/page table) for it. And it makes sense since any such error indicates a potential misunderstanding on the spec. > If that's the case, I'm wondering whether we should always follow the > hardware behavior as an emulator. I think so. and current virtual Intel IOMMU does a good job to detect the SNP setting.:) > Now I'm trying to remember normally how a spec could re-use a bit that was > used to be reserved: should the hardware bumps the version of the version reg > in so > that softwares will know what to expect? defining a new capability bit is also a way for it. New software will probe the capability bit and then program the bit which was reserved but now redefined. Old software doesn’t have any idea on the new capability bit, so it will not program the reserved bit. > So I'm thinking whether the emulator code can identify the version bump by > "scalable mode enabled", if so we know some resved bits are "ignored" now, > and IIUC that's mostly the original proposal to add a quirk when scalable mode > in vtd_init(). do you mean the spec version or? > But again, I really think it should be the spec owner who should have > considered all these.. yes, spec owner should consider it. > e.g. explicitly document "this bit was used to reserved, > but when scalable mode enabled it's ignored and programmable by the guest > driver", or something like that. there is a good example for your above sentence. It's the root table entry and the scalable mode root table entry. In legacy mode, the high 64 bits of root table entry are all reserved. In scalable mode, some of the high 64 bits are used. I think we have defined scalable mode reserved bits macro in the emulator code. But regards to minor changes within a working mode, it may be more common to define a capability bit when a reserved bit is re-used. Regards, Yi Liu
