[PATCH 0/4] kvm-s390: feature patches

[PATCH 0/4] kvm-s390: feature patches

[Christian Borntraeger]

Avi, Marcelo,

here are 4 feature patches for kvm-s390. One patch deals with
the memory management of kvm and allows MAP_PRIVATE. The other
patches implement user space access for some missing registers 
via the ONE_REG ioctls.

Carsten Otte (2):
  kvm-s390: KVM_GET/SET_ONEREG for s390
  kvm-s390: epoch difference and TOD programmable field

Christian Borntraeger (1):
  kvm-s390: add capability indicating COW support

Jason J. herne (1):
  kvm-s390: onereg for timer related registers

 arch/s390/include/asm/kvm.h  |    5 +++
 arch/s390/include/asm/sclp.h |    1 +
 arch/s390/kvm/kvm-s390.c     |   74 ++++++++++++++++++++++++++++++++++++++++++
 drivers/s390/char/sclp_cmd.c |   12 ++++++-
 include/linux/kvm.h          |    1 +
 5 files changed, 92 insertions(+), 1 deletion(-)

-- 
1.7.10.2

[PATCH 1/4] kvm-s390: add capability indicating COW support

[Christian Borntraeger]

Currently qemu/kvm on s390 uses a guest mapping that does not
allow the guest backing page table to be write-protected to
support older systems. On those older systems a host write
protection fault will be delivered to the guest.

Newer systems allow to write-protect the guest backing memory
and let the fault be delivered to the host, thus allowing COW.

Use a capability bit to tell qemu if that is possible.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
 arch/s390/include/asm/sclp.h |    1 +
 arch/s390/kvm/kvm-s390.c     |    4 ++++
 drivers/s390/char/sclp_cmd.c |   12 +++++++++++-
 include/linux/kvm.h          |    1 +
 4 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/arch/s390/include/asm/sclp.h b/arch/s390/include/asm/sclp.h
index fed7bee..bf238c5 100644
--- a/arch/s390/include/asm/sclp.h
+++ b/arch/s390/include/asm/sclp.h
@@ -48,6 +48,7 @@ int sclp_cpu_deconfigure(u8 cpu);
 void sclp_facilities_detect(void);
 unsigned long long sclp_get_rnmax(void);
 unsigned long long sclp_get_rzm(void);
+u8 sclp_get_fac85(void);
 int sclp_sdias_blk_count(void);
 int sclp_sdias_copy(void *dest, int blk_num, int nr_blks);
 int sclp_chp_configure(struct chp_id chpid);
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index e5e3800..5c761bf 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -28,6 +28,7 @@
 #include <asm/pgtable.h>
 #include <asm/nmi.h>
 #include <asm/switch_to.h>
+#include <asm/sclp.h>
 #include "kvm-s390.h"
 #include "gaccess.h"
 
@@ -140,6 +141,9 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_MAX_VCPUS:
 		r = KVM_MAX_VCPUS;
 		break;
+	case KVM_CAP_S390_COW:
+		r = sclp_get_fac85() & 0x2;
+		break;
 	default:
 		r = 0;
 	}
diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c
index 231a1d8..032171e 100644
--- a/drivers/s390/char/sclp_cmd.c
+++ b/drivers/s390/char/sclp_cmd.c
@@ -17,6 +17,7 @@
 #include <linux/mm.h>
 #include <linux/mmzone.h>
 #include <linux/memory.h>
+#include <linux/module.h>
 #include <linux/platform_device.h>
 #include <asm/chpid.h>
 #include <asm/sclp.h>
@@ -38,7 +39,8 @@ struct read_info_sccb {
 	u64	facilities;		/* 48-55 */
 	u8	_reserved2[84 - 56];	/* 56-83 */
 	u8	fac84;			/* 84 */
-	u8	_reserved3[91 - 85];	/* 85-90 */
+	u8	fac85;			/* 85 */
+	u8	_reserved3[91 - 86];	/* 86-90 */
 	u8	flags;			/* 91 */
 	u8	_reserved4[100 - 92];	/* 92-99 */
 	u32	rnsize2;		/* 100-103 */
@@ -51,6 +53,7 @@ static int __initdata early_read_info_sccb_valid;
 
 u64 sclp_facilities;
 static u8 sclp_fac84;
+static u8 sclp_fac85;
 static unsigned long long rzm;
 static unsigned long long rnmax;
 
@@ -112,6 +115,7 @@ void __init sclp_facilities_detect(void)
 	sccb = &early_read_info_sccb;
 	sclp_facilities = sccb->facilities;
 	sclp_fac84 = sccb->fac84;
+	sclp_fac85 = sccb->fac85;
 	rnmax = sccb->rnmax ? sccb->rnmax : sccb->rnmax2;
 	rzm = sccb->rnsize ? sccb->rnsize : sccb->rnsize2;
 	rzm <<= 20;
@@ -127,6 +131,12 @@ unsigned long long sclp_get_rzm(void)
 	return rzm;
 }
 
+u8 sclp_get_fac85(void)
+{
+	return sclp_fac85;
+}
+EXPORT_SYMBOL_GPL(sclp_get_fac85);
+
 /*
  * This function will be called after sclp_facilities_detect(), which gets
  * called from early.c code. Therefore the sccb should have valid contents.
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 8d696cf..09f2b3a 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -616,6 +616,7 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_KVMCLOCK_CTRL 76
 #define KVM_CAP_SIGNAL_MSI 77
 #define KVM_CAP_PPC_GET_SMMU_INFO 78
+#define KVM_CAP_S390_COW 79
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
-- 
1.7.10.2

[PATCH 2/4] kvm-s390: KVM_GET/SET_ONEREG for s390

[Christian Borntraeger]

From: Carsten Otte <cotte@de.ibm.com>

This patch enables KVM_CAP_ONE_REG for s390 and implements stubs
for KVM_GET/SET_ONE_REG. This is based on the ppc implementation.

Signed-off-by: Carsten Otte <cotte@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 arch/s390/kvm/kvm-s390.c |   38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 5c761bf..894b3e4 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -135,6 +135,7 @@ int kvm_dev_ioctl_check_extension(long ext)
 	case KVM_CAP_S390_UCONTROL:
 #endif
 	case KVM_CAP_SYNC_REGS:
+	case KVM_CAP_ONE_REG:
 		r = 1;
 		break;
 	case KVM_CAP_NR_VCPUS:
@@ -439,6 +440,31 @@ int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
 	return 0;
 }
 
+static int kvm_arch_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
+					   struct kvm_one_reg *reg)
+{
+	int r = -EINVAL;
+
+	switch (reg->id) {
+	default:
+		break;
+	}
+
+	return r;
+}
+
+static int kvm_arch_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
+					   struct kvm_one_reg *reg)
+{
+	int r = -EINVAL;
+
+	switch (reg->id) {
+	default:
+		break;
+	}
+
+	return r;
+}
 
 static int kvm_arch_vcpu_ioctl_initial_reset(struct kvm_vcpu *vcpu)
 {
@@ -770,6 +796,18 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 	case KVM_S390_INITIAL_RESET:
 		r = kvm_arch_vcpu_ioctl_initial_reset(vcpu);
 		break;
+	case KVM_SET_ONE_REG:
+	case KVM_GET_ONE_REG: {
+		struct kvm_one_reg reg;
+		r = -EFAULT;
+		if (copy_from_user(&reg, argp, sizeof(reg)))
+			break;
+		if (ioctl == KVM_SET_ONE_REG)
+			r = kvm_arch_vcpu_ioctl_set_one_reg(vcpu, &reg);
+		else
+			r = kvm_arch_vcpu_ioctl_get_one_reg(vcpu, &reg);
+		break;
+	}
 #ifdef CONFIG_KVM_S390_UCONTROL
 	case KVM_S390_UCAS_MAP: {
 		struct kvm_s390_ucas_mapping ucasmap;
-- 
1.7.10.2

[PATCH 3/4] kvm-s390: epoch difference and TOD programmable field

[Christian Borntraeger]

From: Carsten Otte <cotte@de.ibm.com>

This patch makes vcpu epoch difference and the TOD programmable
field accessible from userspace. This is needed in order to
implement a couple of instructions that deal with the time of
day clock on s390, such as SET CLOCK and for migration.

Signed-off-by: Carsten Otte <cotte@de.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 arch/s390/include/asm/kvm.h |    3 +++
 arch/s390/kvm/kvm-s390.c    |   16 ++++++++++++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/s390/include/asm/kvm.h b/arch/s390/include/asm/kvm.h
index 9607667..53a5372 100644
--- a/arch/s390/include/asm/kvm.h
+++ b/arch/s390/include/asm/kvm.h
@@ -52,4 +52,7 @@ struct kvm_sync_regs {
 	__u32 acrs[16];	/* access registers */
 	__u64 crs[16];	/* control registers */
 };
+
+#define KVM_REG_S390_TODPR	(KVM_REG_S390 | KVM_REG_SIZE_U32 | 0x1)
+#define KVM_REG_S390_EPOCHDIFF	(KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x2)
 #endif
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 894b3e4..cc4c013 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -446,6 +446,14 @@ static int kvm_arch_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
 	int r = -EINVAL;
 
 	switch (reg->id) {
+	case KVM_REG_S390_TODPR:
+		r = put_user(vcpu->arch.sie_block->todpr,
+			     (u32 __user *)reg->addr);
+		break;
+	case KVM_REG_S390_EPOCHDIFF:
+		r = put_user(vcpu->arch.sie_block->epoch,
+			     (u64 __user *)reg->addr);
+		break;
 	default:
 		break;
 	}
@@ -459,6 +467,14 @@ static int kvm_arch_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
 	int r = -EINVAL;
 
 	switch (reg->id) {
+	case KVM_REG_S390_TODPR:
+		r = get_user(vcpu->arch.sie_block->todpr,
+			     (u32 __user *)reg->addr);
+		break;
+	case KVM_REG_S390_EPOCHDIFF:
+		r = get_user(vcpu->arch.sie_block->epoch,
+			     (u64 __user *)reg->addr);
+		break;
 	default:
 		break;
 	}
-- 
1.7.10.2

[PATCH 4/4] kvm-s390: onereg for timer related registers

[Christian Borntraeger]

From: "Jason J. herne" <jjherne@us.ibm.com>

Enhance the KVM ONE_REG capability within S390 to allow
getting/setting the following special cpu registers: clock comparator
and the cpu timer. These are needed for migration.

Signed-off-by: Jason J. herne <jjherne@us.ibm.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 arch/s390/include/asm/kvm.h |    2 ++
 arch/s390/kvm/kvm-s390.c    |   16 ++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/arch/s390/include/asm/kvm.h b/arch/s390/include/asm/kvm.h
index 53a5372..bdcbe0f 100644
--- a/arch/s390/include/asm/kvm.h
+++ b/arch/s390/include/asm/kvm.h
@@ -55,4 +55,6 @@ struct kvm_sync_regs {
 
 #define KVM_REG_S390_TODPR	(KVM_REG_S390 | KVM_REG_SIZE_U32 | 0x1)
 #define KVM_REG_S390_EPOCHDIFF	(KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x2)
+#define KVM_REG_S390_CPU_TIMER  (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x3)
+#define KVM_REG_S390_CLOCK_COMP (KVM_REG_S390 | KVM_REG_SIZE_U64 | 0x4)
 #endif
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index cc4c013..664766d 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -454,6 +454,14 @@ static int kvm_arch_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu,
 		r = put_user(vcpu->arch.sie_block->epoch,
 			     (u64 __user *)reg->addr);
 		break;
+	case KVM_REG_S390_CPU_TIMER:
+		r = put_user(vcpu->arch.sie_block->cputm,
+			     (u64 __user *)reg->addr);
+		break;
+	case KVM_REG_S390_CLOCK_COMP:
+		r = put_user(vcpu->arch.sie_block->ckc,
+			     (u64 __user *)reg->addr);
+		break;
 	default:
 		break;
 	}
@@ -475,6 +483,14 @@ static int kvm_arch_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
 		r = get_user(vcpu->arch.sie_block->epoch,
 			     (u64 __user *)reg->addr);
 		break;
+	case KVM_REG_S390_CPU_TIMER:
+		r = get_user(vcpu->arch.sie_block->cputm,
+			     (u64 __user *)reg->addr);
+		break;
+	case KVM_REG_S390_CLOCK_COMP:
+		r = get_user(vcpu->arch.sie_block->ckc,
+			     (u64 __user *)reg->addr);
+		break;
 	default:
 		break;
 	}
-- 
1.7.10.2

Re: [PATCH 1/4] kvm-s390: add capability indicating COW support

[Avi Kivity]

On 05/15/2012 03:15 PM, Christian Borntraeger wrote:
> Currently qemu/kvm on s390 uses a guest mapping that does not
> allow the guest backing page table to be write-protected to
> support older systems. On those older systems a host write
> protection fault will be delivered to the guest.
>
> Newer systems allow to write-protect the guest backing memory
> and let the fault be delivered to the host, thus allowing COW.
>
> Use a capability bit to tell qemu if that is possible.
>

Asking out of ignorance: who is doing the write protection here? The
guest?  If so, why is qemu involved?

Or is qemu just passing the capability on to the guest?

btw, we usually use 'userspace' in kernel patches instead of qemu to
create the illusion that it's not the only consumer of kvm interfaces.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 0/4] kvm-s390: feature patches

[Avi Kivity]

On 05/15/2012 03:15 PM, Christian Borntraeger wrote:
> Avi, Marcelo,
>
> here are 4 feature patches for kvm-s390. One patch deals with
> the memory management of kvm and allows MAP_PRIVATE. The other
> patches implement user space access for some missing registers 
> via the ONE_REG ioctls.
>

Everything looks reasonable.  These patches will miss 3.5 though since
the merge window is so close, unless there's a reason to push them in.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 1/4] kvm-s390: add capability indicating COW support

[Christian Borntraeger]

On 15/05/12 14:24, Avi Kivity wrote:
>> Newer systems allow to write-protect the guest backing memory
>> and let the fault be delivered to the host, thus allowing COW.
>>
>> Use a capability bit to tell qemu if that is possible.
>>
> 
> Asking out of ignorance: who is doing the write protection here? The
> guest?  If so, why is qemu involved?

It is about the host doing write protection of guest/user memory (e.g. for 
dirty pages tracking or KSM)

> btw, we usually use 'userspace' in kernel patches instead of qemu to
> create the illusion that it's not the only consumer of kvm interfaces.

In fact there are other consumers.

Re: [PATCH 1/4] kvm-s390: add capability indicating COW support

[Avi Kivity]

On 05/15/2012 03:31 PM, Christian Borntraeger wrote:
> On 15/05/12 14:24, Avi Kivity wrote:
> >> Newer systems allow to write-protect the guest backing memory
> >> and let the fault be delivered to the host, thus allowing COW.
> >>
> >> Use a capability bit to tell qemu if that is possible.
> >>
> > 
> > Asking out of ignorance: who is doing the write protection here? The
> > guest?  If so, why is qemu involved?
>
> It is about the host doing write protection of guest/user memory (e.g. for 
> dirty pages tracking or KSM)

Ok, so why does qemu^Wuserspace need to know about it?

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 0/4] kvm-s390: feature patches

[Christian Borntraeger]

On 15/05/12 14:26, Avi Kivity wrote:
> Everything looks reasonable.  These patches will miss 3.5 though since
> the merge window is so close, unless there's a reason to push them in.

There is no pressing reason. Of course there are some qemu patches that use these
features, but sooner or later there will be a new header in qemu.

Christian

Re: [PATCH 1/4] kvm-s390: add capability indicating COW support

[Christian Borntraeger]

On 15/05/12 14:33, Avi Kivity wrote:
> On 05/15/2012 03:31 PM, Christian Borntraeger wrote:
>> On 15/05/12 14:24, Avi Kivity wrote:
>>>> Newer systems allow to write-protect the guest backing memory
>>>> and let the fault be delivered to the host, thus allowing COW.
>>>>
>>>> Use a capability bit to tell qemu if that is possible.
>>>>
>>>
>>> Asking out of ignorance: who is doing the write protection here? The
>>> guest?  If so, why is qemu involved?
>>
>> It is about the host doing write protection of guest/user memory (e.g. for 
>> dirty pages tracking or KSM)
> 
> Ok, so why does qemu^Wuserspace need to know about it?

By default qemu will use MAP_PRIVATE for guest pages. This will write
protect pages and thus break on s390 systems that dont support this feature.
Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
has other problems (no dirty pages tracking, a lot more swap overhead etc.)
With this feature qemu can use the standard qemu alloc if available, otherwise
it will use the old s390 hack. I will put you on cc for the qemu patch :-)

Christian

Re: [PATCH 1/4] kvm-s390: add capability indicating COW support

[Avi Kivity]

On 05/15/2012 03:38 PM, Christian Borntraeger wrote:
> On 15/05/12 14:33, Avi Kivity wrote:
> > On 05/15/2012 03:31 PM, Christian Borntraeger wrote:
> >> On 15/05/12 14:24, Avi Kivity wrote:
> >>>> Newer systems allow to write-protect the guest backing memory
> >>>> and let the fault be delivered to the host, thus allowing COW.
> >>>>
> >>>> Use a capability bit to tell qemu if that is possible.
> >>>>
> >>>
> >>> Asking out of ignorance: who is doing the write protection here? The
> >>> guest?  If so, why is qemu involved?
> >>
> >> It is about the host doing write protection of guest/user memory (e.g. for 
> >> dirty pages tracking or KSM)
> > 
> > Ok, so why does qemu^Wuserspace need to know about it?
>
> By default qemu will use MAP_PRIVATE for guest pages. This will write
> protect pages and thus break on s390 systems that dont support this feature.
> Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
> has other problems (no dirty pages tracking, a lot more swap overhead etc.)
> With this feature qemu can use the standard qemu alloc if available, otherwise
> it will use the old s390 hack. I will put you on cc for the qemu patch :-)

Yeah, I even have vague memories of the hack.  Thanks for the
clarifications.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 0/4] kvm-s390: feature patches

[Marcelo Tosatti]

On Tue, May 15, 2012 at 02:15:24PM +0200, Christian Borntraeger wrote:
> Avi, Marcelo,
> 
> here are 4 feature patches for kvm-s390. One patch deals with
> the memory management of kvm and allows MAP_PRIVATE. The other
> patches implement user space access for some missing registers 
> via the ONE_REG ioctls.
> 
> Carsten Otte (2):
>   kvm-s390: KVM_GET/SET_ONEREG for s390
>   kvm-s390: epoch difference and TOD programmable field
> 
> Christian Borntraeger (1):
>   kvm-s390: add capability indicating COW support
> 
> Jason J. herne (1):
>   kvm-s390: onereg for timer related registers
> 
>  arch/s390/include/asm/kvm.h  |    5 +++
>  arch/s390/include/asm/sclp.h |    1 +
>  arch/s390/kvm/kvm-s390.c     |   74 ++++++++++++++++++++++++++++++++++++++++++
>  drivers/s390/char/sclp_cmd.c |   12 ++++++-
>  include/linux/kvm.h          |    1 +
>  5 files changed, 92 insertions(+), 1 deletion(-)

Applied, thanks.

Re: [PATCH 1/4] kvm-s390: add capability indicating COW support

[Alexander Graf]

On 15.05.2012, at 14:38, Christian Borntraeger wrote:

> On 15/05/12 14:33, Avi Kivity wrote:
>> On 05/15/2012 03:31 PM, Christian Borntraeger wrote:
>>> On 15/05/12 14:24, Avi Kivity wrote:
>>>>> Newer systems allow to write-protect the guest backing memory
>>>>> and let the fault be delivered to the host, thus allowing COW.
>>>>> 
>>>>> Use a capability bit to tell qemu if that is possible.
>>>>> 
>>>> 
>>>> Asking out of ignorance: who is doing the write protection here? The
>>>> guest?  If so, why is qemu involved?
>>> 
>>> It is about the host doing write protection of guest/user memory (e.g. for 
>>> dirty pages tracking or KSM)
>> 
>> Ok, so why does qemu^Wuserspace need to know about it?
> 
> By default qemu will use MAP_PRIVATE for guest pages. This will write
> protect pages and thus break on s390 systems that dont support this feature.
> Therefore qemu has a hack to always use MAP_SHARED for s390. But MAP_SHARED
> has other problems (no dirty pages tracking, a lot more swap overhead etc.)
> With this feature qemu can use the standard qemu alloc if available, otherwise
> it will use the old s390 hack. I will put you on cc for the qemu patch :-)

It'd be nice to have that documented somewhere :).


Alex

Re: [PATCH 2/4] kvm-s390: KVM_GET/SET_ONEREG for s390

[Alexander Graf]

On 15.05.2012, at 14:15, Christian Borntraeger wrote:

> From: Carsten Otte <cotte@de.ibm.com>
> 
> This patch enables KVM_CAP_ONE_REG for s390 and implements stubs
> for KVM_GET/SET_ONE_REG. This is based on the ppc implementation.
> 
> Signed-off-by: Carsten Otte <cotte@de.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>

One day we should make this be a true generic interface and not let arch specific code handle it all on their own. But for now, it's good as it is :).

Acked-by: Alexander Graf <agraf@suse.de>


Alex

Re: [PATCH 3/4] kvm-s390: epoch difference and TOD programmable field

[Alexander Graf]

On 15.05.2012, at 14:15, Christian Borntraeger wrote:

> From: Carsten Otte <cotte@de.ibm.com>
> 
> This patch makes vcpu epoch difference and the TOD programmable
> field accessible from userspace. This is needed in order to
> implement a couple of instructions that deal with the time of
> day clock on s390, such as SET CLOCK and for migration.
> 
> Signed-off-by: Carsten Otte <cotte@de.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>

No complaints here.

Acked-by: Alexander Graf <agraf@suse.de>


Alex

Re: [PATCH 4/4] kvm-s390: onereg for timer related registers

[Alexander Graf]

On 15.05.2012, at 14:15, Christian Borntraeger wrote:

> From: "Jason J. herne" <jjherne@us.ibm.com>
> 
> Enhance the KVM ONE_REG capability within S390 to allow
> getting/setting the following special cpu registers: clock comparator
> and the cpu timer. These are needed for migration.
> 
> Signed-off-by: Jason J. herne <jjherne@us.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>

Any other registers we need to expose to user space while we're at it? :)

Acked-by: Alexander Graf <agraf@suse.de>


Alex

Re: [PATCH 4/4] kvm-s390: onereg for timer related registers

[Christian Borntraeger]

On 05/06/12 14:42, Alexander Graf wrote:
> 
> On 15.05.2012, at 14:15, Christian Borntraeger wrote:
> 
>> From: "Jason J. herne" <jjherne@us.ibm.com>
>>
>> Enhance the KVM ONE_REG capability within S390 to allow
>> getting/setting the following special cpu registers: clock comparator
>> and the cpu timer. These are needed for migration.
>>
>> Signed-off-by: Jason J. herne <jjherne@us.ibm.com>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> 
> Any other registers we need to expose to user space while we're at it? :)

I hope not. Life guest relocation prototyping indicates that we have at least
the subset that allows a linux guest to continue.

We might need a way for userspace to influence the output of the store
system information and store facility list instruction. Dont know, maybe
we could use ONEREG even for that purpose. Its on my todo list, but there
are too many other things to tidy up.

Since this would be interface/ABI I dont want to rush without really
understanding what I need for those instruction.

Christian

Re: [PATCH 4/4] kvm-s390: onereg for timer related registers

[Alexander Graf]

On 05.06.2012, at 14:57, Christian Borntraeger wrote:

> On 05/06/12 14:42, Alexander Graf wrote:
>> 
>> On 15.05.2012, at 14:15, Christian Borntraeger wrote:
>> 
>>> From: "Jason J. herne" <jjherne@us.ibm.com>
>>> 
>>> Enhance the KVM ONE_REG capability within S390 to allow
>>> getting/setting the following special cpu registers: clock comparator
>>> and the cpu timer. These are needed for migration.
>>> 
>>> Signed-off-by: Jason J. herne <jjherne@us.ibm.com>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> 
>> Any other registers we need to expose to user space while we're at it? :)
> 
> I hope not. Life guest relocation prototyping indicates that we have at least
> the subset that allows a linux guest to continue.
> 
> We might need a way for userspace to influence the output of the store
> system information and store facility list instruction. Dont know, maybe
> we could use ONEREG even for that purpose. Its on my todo list, but there
> are too many other things to tidy up.

Hrm - not sure if ONEREG is the right interface here. These 2 instructions are more similar to CPUID in that they can have multiple leafs with lots of data each. But then again, which parts exactly would user space care about?

> Since this would be interface/ABI I dont want to rush without really
> understanding what I need for those instruction.

Yup, very good decision :). I was really more thinking of other SIE fields that look obvious.


Alex