[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87po69hnir.fsf@vitty.brq.redhat.com>
Date: Tue, 16 Jan 2018 15:43:56 +0100
From: Vitaly Kuznetsov <vkuznets@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: David Hildenbrand <david@...hat.com>,
Wanpeng Li <kernellwp@...il.com>, kvm <kvm@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
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>,
linux-kernel@...r.kernel.org
Subject: Re: [RFC 0/6] Enlightened VMCS support for KVM on Hyper-V
Paolo Bonzini <pbonzini@...hat.com> writes:
> On 16/01/2018 14:58, Vitaly Kuznetsov wrote:
>>> Haven't looked into the details, but we have to watch out for other
>>> VCPUs trying to modify that vmcs12.
>>>
>>> Basically because other VCPUs could try to modify values in vmcs12 while
>>> we are currently building vmcs02. Nasty races could result in us copying
>>> stuff (probably unchecked) into vmcs02 and therefore running something
>>> that was not intended.
>>>
>> I don't think we share VMCS among vCPUs, do we?
>
> VMCS is just memory, so who knows what a malicious L1 guest will do.
> But for vmread/vmwrite we can go through hypervisor memory, for
> enlightened VMCS we cannot.
>
True; not sure if Hyper-V actually copies the data to some internal
storage, probably it does. TLFS explicitly forbids making the same
enlightened VMCS active on several vCPUs simultaneously but again, this
is just memory...
--
Vitaly
Powered by blists - more mailing lists