In the five years since the original VMCS12 layout was defined, there have been four incompatible changes to the layout. Technically, each of these changes should have also changed the VMCS12_REVISION, but none did. The original layout included several padding fields for future expansion, but these fields have only been used in one of five expansions. Live migration will be much easier if the source and destination hosts implement compatible VMCS12 layouts. New fields can either use existing padding or they can be appended to the end of the existing layout, but existing fields should not be shifted around. Otherwise, we have to be more diligent about changing the VMCS12_REVISION when incompatible changes are made to the layout, and the source and destination hosts will have to implement the same VMCS12_REVISION. (It is certainly conceivable that a host could implement multiple layouts, but that would entail more work than just keeping the layouts compatible.) The question I have is whether or not the current VMCS12 layout is the one that we want to bake in for all time. Other options that come to mind are (1) matching some existing hardware layout (e.g. Broadwell), or (2) creating a layout where the field offsets can be calculated mathematically from the field encoding, rather than through a table lookup. Perhaps there are other reasons for changing the current layout that I'm not considering. Or, perhaps the benefits of any change are too small to warrant the effort. Comments? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
