From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Alexander Graf <agraf@suse.de>
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>
Subject: Re: [Qemu-devel] [PATCH/RFC] s390: Provide a configuration and control device
Date: Tue, 01 Apr 2014 21:23:57 +0200 [thread overview]
Message-ID: <533B124D.4060707@de.ibm.com> (raw)
In-Reply-To: <533AD457.7030701@suse.de>
On 01/04/14 16:59, Alexander Graf wrote:
> 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?
Might be a misleading name here. This is about CPU id and facility list (mostly CPU features).
The list of facilities and the cpu id is unique on VM level. It is queried via a CPU instruction, though. Providing some VM-wide setting via a CPU interface would make the interface look like the user can have different settings per-CPU. Since we cant, its better to make this explicit.
>
>
> 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
>>
>
next prev parent reply other threads:[~2014-04-01 19:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-01 14:47 [Qemu-devel] [PATCH/RFC] s390: Provide a configuration and control device Christian Borntraeger
2014-04-01 14:47 ` [Qemu-devel] [PATCH/RFC] KVM: s390: Add S390 configuration and control kvm device Christian Borntraeger
2014-04-01 14:58 ` Alexander Graf
2014-04-01 15:04 ` Christian Borntraeger
2014-04-01 15:12 ` Alexander Graf
2014-04-01 19:19 ` Christian Borntraeger
2014-04-01 19:36 ` Alexander Graf
2014-04-01 20:08 ` Christian Borntraeger
2014-04-01 19:37 ` Alexander Graf
2014-04-01 14:47 ` [Qemu-devel] [PATCH/RFC] s390x/kvm: implement and use QEMU config device for s390 Christian Borntraeger
2014-04-01 15:38 ` Paolo Bonzini
2014-04-01 18:56 ` Christian Borntraeger
2014-04-01 14:59 ` [Qemu-devel] [PATCH/RFC] s390: Provide a configuration and control device Alexander Graf
2014-04-01 19:23 ` Christian Borntraeger [this message]
2014-04-01 19:37 ` Alexander Graf
2014-04-02 8:31 ` Christian Borntraeger
2014-04-02 8:39 ` Alexander Graf
2014-04-02 8:54 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=533B124D.4060707@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=agraf@suse.de \
--cc=cornelia.huck@de.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=tumanova@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).