From patchwork Wed Apr 2 08:54:00 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Borntraeger X-Patchwork-Id: 3927631 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 97E7EBF540 for ; Wed, 2 Apr 2014 08:54:19 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8DF9620279 for ; Wed, 2 Apr 2014 08:54:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A538C20453 for ; Wed, 2 Apr 2014 08:54:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758188AbaDBIyK (ORCPT ); Wed, 2 Apr 2014 04:54:10 -0400 Received: from e06smtp15.uk.ibm.com ([195.75.94.111]:49621 "EHLO e06smtp15.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758036AbaDBIyG (ORCPT ); Wed, 2 Apr 2014 04:54:06 -0400 Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 Apr 2014 09:54:05 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 2 Apr 2014 09:54:02 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 2D14417D8059; Wed, 2 Apr 2014 09:54:51 +0100 (BST) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4075.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id s328rop631260734; Wed, 2 Apr 2014 08:53:50 GMT Received: from d06av05.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id s328s0l4024900; Wed, 2 Apr 2014 02:54:01 -0600 Received: from [9.152.224.100] (dyn-9-152-224-100.boeblingen.de.ibm.com [9.152.224.100]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id s328s0Ia024872; Wed, 2 Apr 2014 02:54:00 -0600 Message-ID: <533BD028.8060307@de.ibm.com> Date: Wed, 02 Apr 2014 10:54:00 +0200 From: Christian Borntraeger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alexander Graf , Alexander Graf , Paolo Bonzini CC: qemu-devel , KVM , linux-s390 , Cornelia Huck , Michael Mueller , Ekaterina Tumanova , Jens Freimann Subject: Re: [PATCH/RFC] s390: Provide a configuration and control device References: <1396363663-50450-1-git-send-email-borntraeger@de.ibm.com> <533BCAE7.4000000@de.ibm.com> <533BCCD4.3060601@suse.com> In-Reply-To: <533BCCD4.3060601@suse.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14040208-0342-0000-0000-0000084DB7FF Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On 02/04/14 10:39, Alexander Graf wrote: > > On 02.04.14 10:31, Christian Borntraeger wrote: >> On 01/04/14 16:47, 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 >>> >>> >>> >>> 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 >>> >> @Alex, >> >> regarding STSI, what about the following: >> >> The kernel will fill in every part of STSI as of now, but we will provide a CAP that qemu can enable which then tells the kernel to pass control to QEMU after it has filled in the data. QEMU can then do nothing (e.g. for stsi 111) or change >> the information (e.g. for 322) and return to kernel. That would >> a: cover the name aspect >> b: will work with future enhancements for levels 1 and 2 since the kernel will still pass that through to the HW or LPAR >> c: allows QEMU to override everything if necessary > > I like that one, yes. Does the STSI payload fit into our exit payload union? No, its up to 4k. So the STSI exit would need Function code, selector1, and selector2, as well as guest logical address. So something like: index a8f4ee5..3ea5727 100644 >> @Paolo, Alex, >> >> I have several changes pending that will require new ioctls. I planned to use the config device to avoid creating new ioctls. Some option: >> a: define new ioctls for these things (might end up with ~10 new ioctls) >> b: allow GET_ATTR/SET_ATTR on the vm fd. We would define those as architecture specific attributes of the VM. >> c: use a config device an anchor for GET_ATTR/SET_ATTR >> d: any better idea >> >> This question is really a bike shed color discussion (which interface for specific thing between qemu/kvm is considered best), but it will be ABI. Paolo, do you have any preference? >> I dont care about which solution we choose, but I obviously need a decision to rework pending patches. > > I think it semantically makes a lot of sense to treat the VM fd as an "implements device" class :). So allowing GET_ATTR/SET_ATTR on the VM fd makes most sense to me. Paolo, are you ok with allowing GET_ATTR/SET_ATTR/HAS_ATTR on the vm fd. All Attributes are then architecture specific. We might also reserve a group (e.g. 0) to be cross architecture. > As for all the individual bits you need to set, I'd like to make sure we talk about them on a case-by-case basis. As you've seen with STSI, other solutions might be a better fit. Absolutely. There is a reason why this patch has an RFC and not a PULL. Christian --- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -297,6 +297,13 @@ struct kvm_run { __u32 ipb; __u8 dequeued; } s390_tsch; + /* KVM_EXIT_S390_STSI */ + struct { + __u64 addr; + __u8 fc; + __u8 sel1; + __u16 sel2; + } s390_stsi; /* KVM_EXIT_EPR */ struct { __u32 epr;