lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Dec 2017 09:44:01 -0800 From: Jim Mattson <jmattson@...gle.com> To: Vitaly Kuznetsov <vkuznets@...hat.com> Cc: kvm list <kvm@...r.kernel.org>, "the arch/x86 maintainers" <x86@...nel.org>, Paolo Bonzini <pbonzini@...hat.com>, Radim Krčmář <rkrcmar@...hat.com>, "K. Y. Srinivasan" <kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, Stephen Hemminger <sthemmin@...rosoft.com>, "Michael Kelley (EOSG)" <Michael.H.Kelley@...rosoft.com>, Mohammed Gamal <mmorsy@...hat.com>, Cathy Avery <cavery@...hat.com>, Bandan Das <bsd@...hat.com>, Roman Kagan <rkagan@...tuozzo.com>, LKML <linux-kernel@...r.kernel.org>, devel@...uxdriverproject.org Subject: Re: [PATCH RFC 2/7] KVM: nVMX: modify vmcs12 fields to match Hyper-V enlightened VMCS You can change the default VMCS12_REVISION and associated layout, as long as support is maintained for the old layout and userspace has the ability (e.g. by setting the IA32_VMX_BASIC MSR) to specify that a VM needs to use the old layout. On Tue, Dec 19, 2017 at 4:25 AM, Vitaly Kuznetsov <vkuznets@...hat.com> wrote: > Jim Mattson <jmattson@...gle.com> writes: > >> At this point in time, I don't think you can just blithely change the >> virtual VMCS layout and revision number. Existing VMs using the old >> layout and revision number must continue to work on versions of kvm >> past this point. You could tie the layout and revision number changes >> to KVM_CAP_HYPERV_ENLIGHTENED_VMCS if you like, but kvm must be able >> to continue to service VMs using the previous layout and revision >> number in perpetuity. >> > > I see what you mean. In case we need to keep migration of nested > workloads working between KVMs of different versions we can't (ever) > touch vmcs12. > > The way to go in this case, I think, is to create a completely separate > enlightened_vmcs12 struct and use it when appropriate. We can't possibly > support migrating workloads which use enlightened VMCS to an old KVM > which doesn't support it. > > P.S. "If there are changes in this struct, VMCS12_REVISION must be > changed." comment needs to be replaced with "Don't even think about > changing this" :-) > > -- > Vitaly
Powered by blists - more mailing lists