On 21/05/20 10:47, Vitaly Kuznetsov wrote: >>> >> Yes, please do so. The header is exactly for cases like this where we >> have small fields that hold non-architectural pieces of state. >> > This can definitely work here (and I'm not at all against this solution) > but going forward it seems we'll inevitably need a convenient way to > handle sparse/extensible 'data'. Also, the header is 128 bytes only. I'd rather cross that bridge when we get there, so: - for now, add an u32 to the header that indicates the validity of header fields other than smm.flags (in this case the preemption timer deadline) - if we ever add more stuff to the data, we will 1) always include the first 8k for backwards compatibility 2) use another u32 in the header to tell you the validity of the data Addition to the nested state header should be relatively rare, since it's only for non-architectural (implementation-specific) state. Paolo > I'd suggest we add an u32/u64 bit set to the header (which will be separate > for vmx/svm structures) describing what is and what's not in vmx/svm > specific 'data', this way we can easily validate the size and get the > right offsets. Also, we'll start saving bits in arch neutral 'flags' as > we don't have that many :-)
