From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:36782)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1WV0AB-0003Nh-RV
	for qemu-devel@nongnu.org; Tue, 01 Apr 2014 10:59:51 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1WV0A4-0003qI-Bf
	for qemu-devel@nongnu.org; Tue, 01 Apr 2014 10:59:43 -0400
Received: from cantor2.suse.de ([195.135.220.15]:35241 helo=mx2.suse.de)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <agraf@suse.de>) id 1WV0A4-0003pu-4T
	for qemu-devel@nongnu.org; Tue, 01 Apr 2014 10:59:36 -0400
Message-ID: <533AD457.7030701@suse.de>
Date: Tue, 01 Apr 2014 16:59:35 +0200
From: Alexander Graf <agraf@suse.de>
MIME-Version: 1.0
References: <1396363663-50450-1-git-send-email-borntraeger@de.ibm.com>
In-Reply-To: <1396363663-50450-1-git-send-email-borntraeger@de.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH/RFC] s390: Provide a configuration and
	control device
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: linux-s390 <linux-s390@vger.kernel.org>, Michael Mueller <mimu@linux.vnet.ibm.com>, KVM <kvm@vger.kernel.org>, Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>, qemu-devel <qemu-devel@nongnu.org>, Jens Freimann <jfrei@linux.vnet.ibm.com>, Cornelia Huck <cornelia.huck@de.ibm.com>

On 04/01/2014 04:47 PM, Christian Borntraeger wrote:
> We want to configure several things in KVM that go beyond what
> ENABLE_CAP (we need payload) or ONE_REG (we need it for the VM
> and we need to do more complex actions) can provide. Instead of
> adding several s390 specific ioctls, lets provide a configuration
> and control device that encapsulates different commands into
> groups of the same area (MEMORY, CPU, ..)
>
> We also provide an initial nameless base group, with a simple first
> user to set the guest name. We need that name in the kernel for
> the emulation of STSI (which provides the guest name to the guest)
> but we need to implement the emulation in supervisor mode, as it
> also provides the underlying levels of hipervisors.
>
> Currently we have the following GROUPS and ATTRs pending, which
> configure some memory management related function or allow to set
> the guest facilities, cpuids etc:
>
> #define KVM_DEV_CONFIG_GROUP            0
> #define KVM_DEV_CONFIG_NAME             0
>
> #define KVM_DEV_CONFIG_GROUP_MEM        1
> #define KVM_DEV_CONFIG_MEM_ENABLE_CMMA  0
> #define KVM_DEV_CONFIG_MEM_CLR_CMMA     1
> #define KVM_DEV_CONFIG_MEM_CLR_PAGES    2
>
> #define KVM_DEV_CONFIG_GROUP_CPU        2
> #define KVM_DEV_CONFIG_CPU_TYPE         0
> #define KVM_DEV_CONFIG_CPU_FAC          1
> #define KVM_DEV_CONFIG_CPU_FAC_MASK     2
> #define KVM_DEV_CONFIG_CPU_IBC          3
> #define KVM_DEV_CONFIG_CPU_IBC_RANGE    4

Why would CPU specific information be set in the VM?


Alex

>
>
>
> In addition other groups like
> #define KVM_DEV_CONFIG_GROUP_CRYPTO
> are under consideration to configure crypto acceleration.
>
> Unless there is a major concern, I will add this to the next
> s390 PULL requests for KVM.
>
> Christian
>