On Tue, May 01, 2018 at 03:25:58PM -0700, Jim Mattson wrote:
> Oops! Since no one else is impacted by these offsets yet, I'd like to
> reserve locations for the vmread and vmwrite bitmaps, used by
> virtualized VMCS shadowing.
That is fine - what got me saying "Uhoh" was the "save/restore
compatibility" statement.
>
> I know I've lost some credibility after the "save/restore nested
> state" debacle, but I do intend to upstream support for virtualized
> VMCS shadowing soon.
Wooohoo!!
>
> On Mon, Apr 30, 2018 at 2:48 PM, Jim Mattson <jmattson@xxxxxxxxxx> wrote:
> > On Mon, Apr 30, 2018 at 2:14 PM, Konrad Rzeszutek Wilk
> > <konrad.wilk@xxxxxxxxxx> wrote:
> >> On Fri, Apr 27, 2018 at 11:14:35AM -0700, Jim Mattson wrote:
> >>> Changing the VMCS12 layout breaks save/restore compatibility with
> >>> older kvm releases.
> >>>
> >>> Google has been saving/restoring nested VMX state based on the v4.0
> >>> layout. There are no other known users of the
> >>> KVM_{GET,SET}_NESTED_STATE ioctls, since those ioctls have not yet
> >>> been accepted upstream.
> >>
> >> What is the advantage of that layout vs the one that is now? I vaguelly
> >> recall something about it being quite bloated and the newer more sparse?
> >
> > The only differences between the v4.0 layout and today's layout is
> > that four new fields have been intermingled in such a way that the old
> > offsets have not been preserved. I'm suggesting that these four fields
> > be moved so as to preserve the offsets of all of the pre-existing
> > fields.
