[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58f9d2c1-0739-5b72-ee21-285474666c58@redhat.com>
Date: Sat, 12 Sep 2020 18:32:37 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Maxim Levitsky <mlevitsk@...hat.com>, kvm@...r.kernel.org
Cc: Sean Christopherson <sean.j.christopherson@...el.com>,
"open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<linux-kernel@...r.kernel.org>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
Jim Mattson <jmattson@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Joerg Roedel <joro@...tes.org>,
Wanpeng Li <wanpengli@...cent.com>
Subject: Re: [PATCH v3 8/8] KVM: nSVM: implement ondemand allocation of the
nested state
On 27/08/20 19:11, Maxim Levitsky wrote:
> + hsave_page = alloc_page(GFP_KERNEL_ACCOUNT | __GFP_ZERO);
> + if (!hsave_page)
> + goto error;
> +
I think an error here should be just an internal error userspace exit,
or a -ENOMEM from KVM_RUN; not a #GP in the guest[1]. However, that's
difficult to plug into KVM. Can you instead allocate nested state if
KVM_SET_CPUID2 sets the SVM bit? Returning -ENOMEM from KVM_SET_CPUID2
is more likely to be something that userspace copes with.
I queued patches 1-5, and 7 for 5.9-rc.
Paolo
[1] Though in practice an order 0 allocation will never fail
Powered by blists - more mailing lists