From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sean Christopherson Date: Tue, 24 Mar 2020 18:20:48 +0000 Subject: Re: [PATCH v4 19/19] KVM: selftests: Add test for KVM_SET_USER_MEMORY_REGION Message-Id: <20200324182048.GF5998@linux.intel.com> List-Id: References: <20191217204041.10815-1-sean.j.christopherson@intel.com> <20191217204041.10815-20-sean.j.christopherson@intel.com> <20191218163958.GC25201@linux.intel.com> <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> In-Reply-To: <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Christian Borntraeger Cc: James Hogan , Paul Mackerras , Janosch Frank , Paolo Bonzini , Marc Zyngier , David Hildenbrand , Cornelia Huck , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , James Morse , Julien Thierry , Suzuki K Poulose , linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, Christoffer Dall , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= On Tue, Mar 24, 2020 at 10:43:07AM +0100, Christian Borntraeger wrote: > > On 18.12.19 17:39, Sean Christopherson wrote: > > On Wed, Dec 18, 2019 at 12:39:43PM +0100, Christian Borntraeger wrote: > >> > I started looking into this what it would cost to implement this on s390. > s390 is also returning EFAULT if no memory slot is available. > > According to the doc this is not documented at all. So this part of the test > vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > vm_vcpu_add(vm, VCPU_ID); > /* Fails with ENOSPC because the MMU can't create pages (no slots). */ > TEST_ASSERT(_vcpu_run(vm, VCPU_ID) = -1 && errno = ENOSPC, > "Unexpected error code = %d", errno); > kvm_vm_free(vm); > > is actually just testing that the implementation for x86 does not change the error > from ENOSPC to something else. It's even worse than that. There error isn't directly due to no having a memslots, it occurs because the limit on number of pages in the MMU is zero. On x86, that limit is automatically derived from the total size of memslots. The selftest could add an explicit ioctl() call to manually override the number of allowed MMU pages, but that didn't seem any cleaner as it'd still rely on undocumented internal KVM behavior. TL;DR: I'm not a huge fan of the code either. > The question is: do we want to document the error for the "no memslot" case > and then change all existing platforms? At first blush, I like the idea of adding an explicit check in KVM_RUN to return an error if there isn't at least one usable memslot. But, it'd be a little weird/kludgy on x86/VMX due to the existence of "private" memslots, i.e. the check should really fire on "no public memslots". At that point, I'm not sure whether the well defined errno would be worth the extra code. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6411CC43331 for ; Tue, 24 Mar 2020 18:20:58 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 020C8208DB for ; Tue, 24 Mar 2020 18:20:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 020C8208DB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 719774B088; Tue, 24 Mar 2020 14:20:57 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWBBVz6JpX2v; Tue, 24 Mar 2020 14:20:56 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 746C94A534; Tue, 24 Mar 2020 14:20:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C1A764A534 for ; Tue, 24 Mar 2020 14:20:54 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhIRWST--qtx for ; Tue, 24 Mar 2020 14:20:53 -0400 (EDT) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id C687A4A4FC for ; Tue, 24 Mar 2020 14:20:52 -0400 (EDT) IronPort-SDR: 1rCHWtK6NwAbt81UNTxPXyydDpsekNcB9fK7UrmycbkcdUV9b/haNeKF72l1A2RPLNXNSctN7X zjUVZug3MvVQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2020 11:20:51 -0700 IronPort-SDR: y/USM2b3SPl0LjjMZJcqAmjb2PYOuW/QAtqFht1aEDTm2RWTprcUGxDRQvFy8adhtqpy78sfUX 6Y7gyFMhw+XA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,301,1580803200"; d="scan'208";a="246803473" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga003.jf.intel.com with ESMTP; 24 Mar 2020 11:20:48 -0700 Date: Tue, 24 Mar 2020 11:20:48 -0700 From: Sean Christopherson To: Christian Borntraeger Subject: Re: [PATCH v4 19/19] KVM: selftests: Add test for KVM_SET_USER_MEMORY_REGION Message-ID: <20200324182048.GF5998@linux.intel.com> References: <20191217204041.10815-1-sean.j.christopherson@intel.com> <20191217204041.10815-20-sean.j.christopherson@intel.com> <20191218163958.GC25201@linux.intel.com> <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Cc: Wanpeng Li , kvm@vger.kernel.org, David Hildenbrand , James Hogan , linux-mips@vger.kernel.org, Paul Mackerras , kvmarm@lists.cs.columbia.edu, Janosch Frank , Marc Zyngier , Joerg Roedel , kvm-ppc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jim Mattson , Cornelia Huck , linux-kernel@vger.kernel.org, Paolo Bonzini , Vitaly Kuznetsov , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Tue, Mar 24, 2020 at 10:43:07AM +0100, Christian Borntraeger wrote: > > On 18.12.19 17:39, Sean Christopherson wrote: > > On Wed, Dec 18, 2019 at 12:39:43PM +0100, Christian Borntraeger wrote: > >> > I started looking into this what it would cost to implement this on s390. > s390 is also returning EFAULT if no memory slot is available. > > According to the doc this is not documented at all. So this part of the test > vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > vm_vcpu_add(vm, VCPU_ID); > /* Fails with ENOSPC because the MMU can't create pages (no slots). */ > TEST_ASSERT(_vcpu_run(vm, VCPU_ID) == -1 && errno == ENOSPC, > "Unexpected error code = %d", errno); > kvm_vm_free(vm); > > is actually just testing that the implementation for x86 does not change the error > from ENOSPC to something else. It's even worse than that. There error isn't directly due to no having a memslots, it occurs because the limit on number of pages in the MMU is zero. On x86, that limit is automatically derived from the total size of memslots. The selftest could add an explicit ioctl() call to manually override the number of allowed MMU pages, but that didn't seem any cleaner as it'd still rely on undocumented internal KVM behavior. TL;DR: I'm not a huge fan of the code either. > The question is: do we want to document the error for the "no memslot" case > and then change all existing platforms? At first blush, I like the idea of adding an explicit check in KVM_RUN to return an error if there isn't at least one usable memslot. But, it'd be a little weird/kludgy on x86/VMX due to the existence of "private" memslots, i.e. the check should really fire on "no public memslots". At that point, I'm not sure whether the well defined errno would be worth the extra code. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91E7FC54EEB for ; Tue, 24 Mar 2020 18:21:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 794AE20775 for ; Tue, 24 Mar 2020 18:21:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728078AbgCXSVF (ORCPT ); Tue, 24 Mar 2020 14:21:05 -0400 Received: from mga07.intel.com ([134.134.136.100]:33976 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727379AbgCXSVF (ORCPT ); Tue, 24 Mar 2020 14:21:05 -0400 IronPort-SDR: YQ3IlUFAH0UZqrqfbHRQFKDbyJPAoPvGXPiPAD5m7KxpOAgbGtqmui7L6Ir88TyoRaoHDXx9Uj Q7HOy6mgj47w== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2020 11:20:50 -0700 IronPort-SDR: y/USM2b3SPl0LjjMZJcqAmjb2PYOuW/QAtqFht1aEDTm2RWTprcUGxDRQvFy8adhtqpy78sfUX 6Y7gyFMhw+XA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,301,1580803200"; d="scan'208";a="246803473" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga003.jf.intel.com with ESMTP; 24 Mar 2020 11:20:48 -0700 Date: Tue, 24 Mar 2020 11:20:48 -0700 From: Sean Christopherson To: Christian Borntraeger Cc: James Hogan , Paul Mackerras , Janosch Frank , Paolo Bonzini , Marc Zyngier , David Hildenbrand , Cornelia Huck , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , James Morse , Julien Thierry , Suzuki K Poulose , linux-mips@vger.kernel.org, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, Christoffer Dall , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= Subject: Re: [PATCH v4 19/19] KVM: selftests: Add test for KVM_SET_USER_MEMORY_REGION Message-ID: <20200324182048.GF5998@linux.intel.com> References: <20191217204041.10815-1-sean.j.christopherson@intel.com> <20191217204041.10815-20-sean.j.christopherson@intel.com> <20191218163958.GC25201@linux.intel.com> <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-mips-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Tue, Mar 24, 2020 at 10:43:07AM +0100, Christian Borntraeger wrote: > > On 18.12.19 17:39, Sean Christopherson wrote: > > On Wed, Dec 18, 2019 at 12:39:43PM +0100, Christian Borntraeger wrote: > >> > I started looking into this what it would cost to implement this on s390. > s390 is also returning EFAULT if no memory slot is available. > > According to the doc this is not documented at all. So this part of the test > vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > vm_vcpu_add(vm, VCPU_ID); > /* Fails with ENOSPC because the MMU can't create pages (no slots). */ > TEST_ASSERT(_vcpu_run(vm, VCPU_ID) == -1 && errno == ENOSPC, > "Unexpected error code = %d", errno); > kvm_vm_free(vm); > > is actually just testing that the implementation for x86 does not change the error > from ENOSPC to something else. It's even worse than that. There error isn't directly due to no having a memslots, it occurs because the limit on number of pages in the MMU is zero. On x86, that limit is automatically derived from the total size of memslots. The selftest could add an explicit ioctl() call to manually override the number of allowed MMU pages, but that didn't seem any cleaner as it'd still rely on undocumented internal KVM behavior. TL;DR: I'm not a huge fan of the code either. > The question is: do we want to document the error for the "no memslot" case > and then change all existing platforms? At first blush, I like the idea of adding an explicit check in KVM_RUN to return an error if there isn't at least one usable memslot. But, it'd be a little weird/kludgy on x86/VMX due to the existence of "private" memslots, i.e. the check should really fire on "no public memslots". At that point, I'm not sure whether the well defined errno would be worth the extra code. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B0F7C2BAEE for ; Tue, 24 Mar 2020 18:20:57 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D13F72076E for ; Tue, 24 Mar 2020 18:20:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="N0PSFEQ5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D13F72076E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=09AU2fp+54APph+kFjX6qk/VUNRwhl7O6ekvHHS46C4=; b=N0PSFEQ5txhtZB RvvCUhvMJplcT7iTXnyITxmsBJ+QJnkF7CbQMq1ZgOKVqGv8MaUTfKv2XDKrOxBhPFIWRePZhkEA7 FhWrZBHQvl8bBEnhz1nsJ1mPcoz2W8HVpKBcVUCOQFzNq679nN3+ZqTJ6QY0YESHwiat1b699YmGN fI6MRfChJbeQ5WiEo9H+RzFT8jqQ0Hu1/Jm0JoPM/sPmlPlmEAQJO7JfLEyTpKwtUcgPmQHPZzi0C xVzA0BQYCX3OEZ8uztLRvQqq+g2bENINkzXGKjUiXIK4cq5H030PxNM+X13ACzcuKnyZZKUFCTxB3 Abn/RjnXnlGzoBxroswg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jGoAa-00087k-CY; Tue, 24 Mar 2020 18:20:56 +0000 Received: from mga02.intel.com ([134.134.136.20]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jGoAW-00086x-Gg for linux-arm-kernel@lists.infradead.org; Tue, 24 Mar 2020 18:20:54 +0000 IronPort-SDR: Ah1I14FKuZkhE7JPFCkyK77LEWee1ITY1RVCDuSPmyASLrf5OuxrR8b0rAMxxS+S36SCIXMVC3 XJNwAllLq0Vg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2020 11:20:51 -0700 IronPort-SDR: y/USM2b3SPl0LjjMZJcqAmjb2PYOuW/QAtqFht1aEDTm2RWTprcUGxDRQvFy8adhtqpy78sfUX 6Y7gyFMhw+XA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,301,1580803200"; d="scan'208";a="246803473" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga003.jf.intel.com with ESMTP; 24 Mar 2020 11:20:48 -0700 Date: Tue, 24 Mar 2020 11:20:48 -0700 From: Sean Christopherson To: Christian Borntraeger Subject: Re: [PATCH v4 19/19] KVM: selftests: Add test for KVM_SET_USER_MEMORY_REGION Message-ID: <20200324182048.GF5998@linux.intel.com> References: <20191217204041.10815-1-sean.j.christopherson@intel.com> <20191217204041.10815-20-sean.j.christopherson@intel.com> <20191218163958.GC25201@linux.intel.com> <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <78b21097-52e4-b851-fc78-da3442fd0904@de.ibm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200324_112052_602196_AC70546B X-CRM114-Status: GOOD ( 17.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wanpeng Li , kvm@vger.kernel.org, David Hildenbrand , James Hogan , linux-mips@vger.kernel.org, Paul Mackerras , kvmarm@lists.cs.columbia.edu, Janosch Frank , Marc Zyngier , Joerg Roedel , Julien Thierry , Suzuki K Poulose , kvm-ppc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Jim Mattson , Cornelia Huck , Christoffer Dall , linux-kernel@vger.kernel.org, James Morse , Paolo Bonzini , Vitaly Kuznetsov , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Mar 24, 2020 at 10:43:07AM +0100, Christian Borntraeger wrote: > > On 18.12.19 17:39, Sean Christopherson wrote: > > On Wed, Dec 18, 2019 at 12:39:43PM +0100, Christian Borntraeger wrote: > >> > I started looking into this what it would cost to implement this on s390. > s390 is also returning EFAULT if no memory slot is available. > > According to the doc this is not documented at all. So this part of the test > vm = vm_create(VM_MODE_DEFAULT, 0, O_RDWR); > vm_vcpu_add(vm, VCPU_ID); > /* Fails with ENOSPC because the MMU can't create pages (no slots). */ > TEST_ASSERT(_vcpu_run(vm, VCPU_ID) == -1 && errno == ENOSPC, > "Unexpected error code = %d", errno); > kvm_vm_free(vm); > > is actually just testing that the implementation for x86 does not change the error > from ENOSPC to something else. It's even worse than that. There error isn't directly due to no having a memslots, it occurs because the limit on number of pages in the MMU is zero. On x86, that limit is automatically derived from the total size of memslots. The selftest could add an explicit ioctl() call to manually override the number of allowed MMU pages, but that didn't seem any cleaner as it'd still rely on undocumented internal KVM behavior. TL;DR: I'm not a huge fan of the code either. > The question is: do we want to document the error for the "no memslot" case > and then change all existing platforms? At first blush, I like the idea of adding an explicit check in KVM_RUN to return an error if there isn't at least one usable memslot. But, it'd be a little weird/kludgy on x86/VMX due to the existence of "private" memslots, i.e. the check should really fire on "no public memslots". At that point, I'm not sure whether the well defined errno would be worth the extra code. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel