[PATCH v2 2/3] KVM: PPC: epapr: Add idle hcall support for host

2012-01-05 Thread Liu Yu 
And add a new flag definition in kvm_ppc_pvinfo to indicate
whether host support EV_IDLE hcall.

Signed-off-by: Liu Yu yu@freescale.com
---
v2:
1. instead of adding new field in kvm_ppc_pvinfo, use flags.
2. expose hcall definitions to userspace

 arch/powerpc/include/asm/kvm_para.h |   14 --
 arch/powerpc/kvm/powerpc.c  |8 
 include/linux/kvm.h |2 ++
 3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_para.h 
b/arch/powerpc/include/asm/kvm_para.h
index 50533f9..e8632b6 100644
--- a/arch/powerpc/include/asm/kvm_para.h
+++ b/arch/powerpc/include/asm/kvm_para.h
@@ -41,9 +41,19 @@ struct kvm_vcpu_arch_shared {
 };
 
 #define KVM_SC_MAGIC_R00x4b564d21 /* KVM! */
-#define HC_VENDOR_KVM  (42  16)
+
+#include asm/epapr_hcalls.h
+
+/* ePAPR Hypercall Vendor ID */
+#define HC_VENDOR_EPAPR(EV_EPAPR_VENDOR_ID  16)
+#define HC_VENDOR_KVM  (EV_KVM_VENDOR_ID  16)
+
+/* ePAPR Hypercall Token */
+#define HC_EV_IDLE EV_IDLE
+
+/* ePAPR Hypercall Return Codes */
 #define HC_EV_SUCCESS  0
-#define HC_EV_UNIMPLEMENTED12
+#define HC_EV_UNIMPLEMENTEDEV_UNIMPLEMENTED
 
 #define KVM_FEATURE_MAGIC_PAGE 1
 
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index c33f6a7..1242ee1 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -81,6 +81,10 @@ int kvmppc_kvm_pv(struct kvm_vcpu *vcpu)
 
/* Second return value is in r4 */
break;
+   case HC_VENDOR_EPAPR | HC_EV_IDLE:
+   r = HC_EV_SUCCESS;
+   kvm_vcpu_block(vcpu);
+   break;
default:
r = HC_EV_UNIMPLEMENTED;
break;
@@ -772,6 +776,10 @@ static int kvm_vm_ioctl_get_pvinfo(struct kvm_ppc_pvinfo 
*pvinfo)
pvinfo-hcall[2] = inst_sc;
pvinfo-hcall[3] = inst_nop;
 
+#ifdef CONFIG_BOOKE
+   pvinfo-flags |= KVM_PPC_PVINFO_FLAGS_EV_IDLE;
+#endif
+
return 0;
 }
 
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index c107fae..501712d 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -429,6 +429,8 @@ struct kvm_ppc_pvinfo {
__u8  pad[108];
 };
 
+#define KVM_PPC_PVINFO_FLAGS_EV_IDLE   (10)
+
 #define KVMIO 0xAE
 
 /*
-- 
1.6.4


--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/50] KVM: PPC: Add support for explicit HIOR setting

2012-01-05 Thread Scott Wood 
On 01/04/2012 08:36 PM, Alexander Graf wrote:
 
 On 04.01.2012, at 21:12, Scott Wood wrote:
 
 On 01/03/2012 07:10 PM, Alexander Graf wrote:
 diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
 index 25964ee..fb3fddc 100644
 --- a/arch/powerpc/include/asm/kvm.h
 +++ b/arch/powerpc/include/asm/kvm.h
 @@ -327,4 +327,6 @@ struct kvm_book3e_206_tlb_params {
 __u32 reserved[8];
 };

 +#define KVM_ONE_REG_PPC_HIOR   KVM_ONE_REG_PPC | 0x100

 Where does 0x100 come from?
 
 I quite frankly don't remember :). This could just as well be 0 or 1.
 
 There should probaly be some structure to the register space, with a
 subarch field distinguishing between common SPR, book3s SPR, book3e
 SPR, along with others for non-SPR registers, KVM inventions, etc.
 
 Not sure we really need this. I would very much prefer to just always
 use the textual representation. What would we do if something book3s
 specific suddenly becomes generic (like Altivec for example, or
 FPU)?

Good point... A plain enumeration should be fine.  0x100 was strange
enough that it left me wondering what the value should be for the next
register to be added -- I didn't want it to turn into something like the
booke regs-trap mess, where some exceptions re-use the classic offsets,
and other exceptions have numbers that seem to be pulled from out of
nowhere.

-Scott

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/50] KVM: PPC: Add generic single register ioctls

2012-01-05 Thread Scott Wood 
On 01/04/2012 10:07 PM, Alexander Graf wrote:
 Ok here's another idea on how to handle this. What if we encode the
 register size in the constant? That way, if the register grows later,
 we can still be backwards compatible, but give user space exactly the
 size it asks for.
 
 We could then just take a void* from user space and merely c_t_u and c_f_u 
 the value in exactly the size defined by the constant.
 Later, for MANY_REGS we could then just take a list of registers and write a 
 bytestream of results to a user pointer.
 
 That should be a lot easier and efficient than an interface that treats 
 everything as u64.

OK.

 Alex
 

 Btw, any reason you're only bringing up these really great ideas on my 2nd 
 pull request after these patches were uncommented on the ML for quite a 
 while? :)

Sorry about that -- I was trying to focus on getting e500mc patches out
before vacation (and various other distractions), and missed looking at
the patch itself the first time around.

-Scott

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/50] KVM: PPC: Add support for explicit HIOR setting

2012-01-05 Thread Alexander Graf 

On 05.01.2012, at 18:16, Scott Wood wrote:

 On 01/04/2012 08:36 PM, Alexander Graf wrote:
 
 On 04.01.2012, at 21:12, Scott Wood wrote:
 
 On 01/03/2012 07:10 PM, Alexander Graf wrote:
 diff --git a/arch/powerpc/include/asm/kvm.h 
 b/arch/powerpc/include/asm/kvm.h
 index 25964ee..fb3fddc 100644
 --- a/arch/powerpc/include/asm/kvm.h
 +++ b/arch/powerpc/include/asm/kvm.h
 @@ -327,4 +327,6 @@ struct kvm_book3e_206_tlb_params {
__u32 reserved[8];
 };
 
 +#define KVM_ONE_REG_PPC_HIOR  KVM_ONE_REG_PPC | 0x100
 
 Where does 0x100 come from?
 
 I quite frankly don't remember :). This could just as well be 0 or 1.
 
 There should probaly be some structure to the register space, with a
 subarch field distinguishing between common SPR, book3s SPR, book3e
 SPR, along with others for non-SPR registers, KVM inventions, etc.
 
 Not sure we really need this. I would very much prefer to just always
 use the textual representation. What would we do if something book3s
 specific suddenly becomes generic (like Altivec for example, or
 FPU)?
 
 Good point... A plain enumeration should be fine.  0x100 was strange
 enough that it left me wondering what the value should be for the next
 register to be added -- I didn't want it to turn into something like the
 booke regs-trap mess, where some exceptions re-use the classic offsets,
 and other exceptions have numbers that seem to be pulled from out of
 nowhere.

Yup. I'll change it to something lower.

Also we're already using KVM_REG for MMIO register identifiers. But I guess we 
can just reuse the namespace as long as we're careful to not overlap them later.

#define KVM_REG_MASK0x001f
#define KVM_REG_EXT_MASK0xffe0
#define KVM_REG_GPR 0x
#define KVM_REG_FPR 0x0020
#define KVM_REG_QPR 0x0040
#define KVM_REG_FQPR0x0060


Alex

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] GET/SET_ONE_REG and HIOR patches v2

2012-01-05 Thread Alexander Graf 
This is a revised version of the ONE_REG interface. The main difference to v1
is that we now encode the register size in the constant, making it very
unambiguous what size it is. That way we can just take a pointer from user space
to write it to.

Thanks a lot to Scott for reviewing the previous patches and pointing out
some design issues before it actually lands upstream.

Alex

Alexander Graf (2):
  KVM: PPC: Add generic single register ioctls
  KVM: PPC: Add support for explicit HIOR setting

Paul Mackerras (1):
  KVM: PPC: Move kvm_vcpu_ioctl_[gs]et_one_reg down to
platform-specific code

 Documentation/virtual/kvm/api.txt |   41 +
 arch/powerpc/include/asm/kvm.h|2 +
 arch/powerpc/include/asm/kvm_book3s.h |2 +
 arch/powerpc/include/asm/kvm_ppc.h|3 ++
 arch/powerpc/kvm/book3s_hv.c  |   36 +
 arch/powerpc/kvm/book3s_pr.c  |   38 +-
 arch/powerpc/kvm/booke.c  |   10 
 arch/powerpc/kvm/powerpc.c|   26 +
 include/linux/kvm.h   |   36 +
 9 files changed, 192 insertions(+), 2 deletions(-)

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] KVM: PPC: Add generic single register ioctls

2012-01-05 Thread Alexander Graf 
Right now we transfer a static struct every time we want to get or set
registers. Unfortunately, over time we realize that there are more of
these than we thought of before and the extensibility and flexibility of
transferring a full struct every time is limited.

So this is a new approach to the problem. With these new ioctls, we can
get and set a single register that is identified by an ID. This allows for
very precise and limited transmittal of data. When we later realize that
it's a better idea to shove over multiple registers at once, we can reuse
most of the infrastructure and simply implement a GET_MANY_REGS / SET_MANY_REGS
interface.

The only downpoint I see to this one is that it needs to pad to 1024 bits
(hardware is already on 512 bit registers, so I wanted to leave some room)
which is slightly too much for transmitting only 64 bits. But if that's all
the tradeoff we have to do for getting an extensible interface, I'd say go
for it nevertheless.

Signed-off-by: Alexander Graf ag...@suse.de

---

v1 - v2:

  - rename KVM_ONE_REG to KVM_REG
  - change semantics to include size in constant
and a user pointer to write/read to/from
  - update documentation respectively
---
 Documentation/virtual/kvm/api.txt |   40 +
 arch/powerpc/kvm/powerpc.c|   51 +
 include/linux/kvm.h   |   35 +
 3 files changed, 126 insertions(+), 0 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index a4d7b4d..8494214 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1523,6 +1523,46 @@ following algorithm:
 Some guests configure the LINT1 NMI input to cause a panic, aiding in
 debugging.
 
+4.65 KVM_SET_ONE_REG
+
+Capability: KVM_CAP_ONE_REG
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_one_reg (in)
+Returns: 0 on success, negative value on failure
+
+struct kvm_one_reg {
+   __u64 id;
+   __u64 addr;
+};
+
+Using this ioctl, a single vcpu register can be set to a specific value
+defined by user space with the passed in struct kvm_one_reg, where id
+refers to the register identifier as described below and addr is a pointer
+to a variable with the respective size. There can be architecture agnostic
+and architecture specific registers. Each have their own range of operation
+and their own constants and width. To keep track of the implemented
+registers, find a list below:
+
+  Arch  |   Register| Width (bits)
+|   |
+
+4.66 KVM_GET_ONE_REG
+
+Capability: KVM_CAP_ONE_REG
+Architectures: all
+Type: vcpu ioctl
+Parameters: struct kvm_one_reg (in and out)
+Returns: 0 on success, negative value on failure
+
+This ioctl allows to receive the value of a single register implemented
+in a vcpu. The register to read is indicated by the id field of the
+kvm_one_reg struct passed in. On success, the register value can be found
+at the memory location pointed to by addr.
+
+The list of registers accessible using this interface is identical to the
+list in 4.64.
+
 5. The kvm_run structure
 
 Application code obtains a pointer to the kvm_run structure by
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 76993eb..9c598b6 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -214,6 +214,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PPC_UNSET_IRQ:
case KVM_CAP_PPC_IRQ_LEVEL:
case KVM_CAP_ENABLE_CAP:
+   case KVM_CAP_ONE_REG:
r = 1;
break;
 #ifndef CONFIG_KVM_BOOK3S_64_HV
@@ -642,6 +643,32 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
return r;
 }
 
+static int kvm_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_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
+ struct kvm_one_reg *reg)
+{
+   int r = -EINVAL;
+
+   switch (reg-id) {
+   default:
+   break;
+   }
+
+   return r;
+}
+
 int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
 struct kvm_mp_state *mp_state)
 {
@@ -681,6 +708,30 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
break;
}
 
+   case KVM_GET_ONE_REG:
+   {
+   struct kvm_one_reg reg;
+   r = -EFAULT;
+   if (copy_from_user(reg, argp, sizeof(reg)))
+   goto out;
+   r = kvm_vcpu_ioctl_get_one_reg(vcpu, reg);
+   if (copy_to_user(argp, reg, sizeof(reg))) {
+   r = -EFAULT;
+   goto out;
+   }
+   break;
+   }
+
+   case

[PATCH 2/3] KVM: PPC: Add support for explicit HIOR setting

2012-01-05 Thread Alexander Graf 
Until now, we always set HIOR based on the PVR, but this is just wrong.
Instead, we should be setting HIOR explicitly, so user space can decide
what the initial HIOR value is - just like on real hardware.

We keep the old PVR based way around for backwards compatibility, but
once user space uses the SET_ONE_REG based method, we drop the PVR logic.

Signed-off-by: Alexander Graf ag...@suse.de

---

v1 - v2:

  - rename KVM_ONE_REG to KVM_REG
  - add size information to HIOR
  - change HIOR number to 1, indicating that numbers are consecutive
---
 Documentation/virtual/kvm/api.txt |1 +
 arch/powerpc/include/asm/kvm.h|2 ++
 arch/powerpc/include/asm/kvm_book3s.h |2 ++
 arch/powerpc/kvm/book3s_pr.c  |6 --
 arch/powerpc/kvm/powerpc.c|   13 +
 include/linux/kvm.h   |1 +
 6 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/Documentation/virtual/kvm/api.txt 
b/Documentation/virtual/kvm/api.txt
index 8494214..d73b8ea 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1546,6 +1546,7 @@ registers, find a list below:
 
   Arch  |   Register| Width (bits)
 |   |
+  PPC   | KVM_REG_PPC_HIOR  | 64
 
 4.66 KVM_GET_ONE_REG
 
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index 25964ee..7e9e24d 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -327,4 +327,6 @@ struct kvm_book3e_206_tlb_params {
__u32 reserved[8];
 };
 
+#define KVM_REG_PPC_HIOR   KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x1
+
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index 3c3edee..aa795cc 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -90,6 +90,8 @@ struct kvmppc_vcpu_book3s {
 #endif
int context_id[SID_CONTEXTS];
 
+   bool hior_explicit; /* HIOR is set by ioctl, not PVR */
+
struct hlist_head hpte_hash_pte[HPTEG_HASH_NUM_PTE];
struct hlist_head hpte_hash_pte_long[HPTEG_HASH_NUM_PTE_LONG];
struct hlist_head hpte_hash_vpte[HPTEG_HASH_NUM_VPTE];
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index c193625..00efda6 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -157,14 +157,16 @@ void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr)
 #ifdef CONFIG_PPC_BOOK3S_64
if ((pvr = 0x33)  (pvr  0x7033)) {
kvmppc_mmu_book3s_64_init(vcpu);
-   to_book3s(vcpu)-hior = 0xfff0;
+   if (!to_book3s(vcpu)-hior_explicit)
+   to_book3s(vcpu)-hior = 0xfff0;
to_book3s(vcpu)-msr_mask = 0xULL;
vcpu-arch.cpu_type = KVM_CPU_3S_64;
} else
 #endif
{
kvmppc_mmu_book3s_32_init(vcpu);
-   to_book3s(vcpu)-hior = 0;
+   if (!to_book3s(vcpu)-hior_explicit)
+   to_book3s(vcpu)-hior = 0;
to_book3s(vcpu)-msr_mask = 0xULL;
vcpu-arch.cpu_type = KVM_CPU_3S_32;
}
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 9c598b6..4223c6f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -209,6 +209,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_PPC_BOOKE_SREGS:
 #else
case KVM_CAP_PPC_SEGSTATE:
+   case KVM_CAP_PPC_HIOR:
case KVM_CAP_PPC_PAPR:
 #endif
case KVM_CAP_PPC_UNSET_IRQ:
@@ -649,6 +650,11 @@ static int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu 
*vcpu,
int r = -EINVAL;
 
switch (reg-id) {
+#ifdef CONFIG_PPC_BOOK3S
+   case KVM_REG_PPC_HIOR:
+   r = put_user(to_book3s(vcpu)-hior, (u64 __user *)reg-addr);
+   break;
+#endif
default:
break;
}
@@ -662,6 +668,13 @@ static int kvm_vcpu_ioctl_set_one_reg(struct kvm_vcpu 
*vcpu,
int r = -EINVAL;
 
switch (reg-id) {
+#ifdef CONFIG_PPC_BOOK3S
+   case KVM_ONE_REG_PPC_HIOR:
+   r = get_user(to_book3s(vcpu)-hior, (u64 __user *)reg-addr);
+   if (!r)
+   to_book3s(vcpu)-hior_explicit = true;
+   break;
+#endif
default:
break;
}
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 31fce98..125f1bc 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -555,6 +555,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_SMT 64
 #define KVM_CAP_PPC_RMA65
 #define KVM_CAP_MAX_VCPUS 66   /* returns max vcpus per vm */
+#define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_SW_TLB 69
 #define KVM_CAP_ONE_REG 70
-- 
1.6.0.2

--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to

Re: [PATCH 1/3] KVM: PPC: Add generic single register ioctls

2012-01-05 Thread Alexander Graf 

On 06.01.2012, at 04:59, Alexander Graf wrote:

 Right now we transfer a static struct every time we want to get or set
 registers. Unfortunately, over time we realize that there are more of
 these than we thought of before and the extensibility and flexibility of
 transferring a full struct every time is limited.
 
 So this is a new approach to the problem. With these new ioctls, we can
 get and set a single register that is identified by an ID. This allows for
 very precise and limited transmittal of data. When we later realize that
 it's a better idea to shove over multiple registers at once, we can reuse
 most of the infrastructure and simply implement a GET_MANY_REGS / 
 SET_MANY_REGS
 interface.
 
 The only downpoint I see to this one is that it needs to pad to 1024 bits
 (hardware is already on 512 bit registers, so I wanted to leave some room)
 which is slightly too much for transmitting only 64 bits. But if that's all
 the tradeoff we have to do for getting an extensible interface, I'd say go
 for it nevertheless.
 
 Signed-off-by: Alexander Graf ag...@suse.de
 
 ---
 
 v1 - v2:
 
  - rename KVM_ONE_REG to KVM_REG
  - change semantics to include size in constant
and a user pointer to write/read to/from
  - update documentation respectively
 ---
 Documentation/virtual/kvm/api.txt |   40 +
 arch/powerpc/kvm/powerpc.c|   51 +
 include/linux/kvm.h   |   35 +
 3 files changed, 126 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/virtual/kvm/api.txt 
 b/Documentation/virtual/kvm/api.txt
 index a4d7b4d..8494214 100644
 --- a/Documentation/virtual/kvm/api.txt
 +++ b/Documentation/virtual/kvm/api.txt
 @@ -1523,6 +1523,46 @@ following algorithm:
 Some guests configure the LINT1 NMI input to cause a panic, aiding in
 debugging.
 
 +4.65 KVM_SET_ONE_REG
 +
 +Capability: KVM_CAP_ONE_REG
 +Architectures: all
 +Type: vcpu ioctl
 +Parameters: struct kvm_one_reg (in)
 +Returns: 0 on success, negative value on failure
 +
 +struct kvm_one_reg {
 +   __u64 id;
 +   __u64 addr;
 +};
 +
 +Using this ioctl, a single vcpu register can be set to a specific value
 +defined by user space with the passed in struct kvm_one_reg, where id
 +refers to the register identifier as described below and addr is a pointer
 +to a variable with the respective size. There can be architecture agnostic
 +and architecture specific registers. Each have their own range of operation
 +and their own constants and width. To keep track of the implemented
 +registers, find a list below:
 +
 +  Arch  |   Register| Width (bits)
 +|   |
 +
 +4.66 KVM_GET_ONE_REG
 +
 +Capability: KVM_CAP_ONE_REG
 +Architectures: all
 +Type: vcpu ioctl
 +Parameters: struct kvm_one_reg (in and out)
 +Returns: 0 on success, negative value on failure
 +
 +This ioctl allows to receive the value of a single register implemented
 +in a vcpu. The register to read is indicated by the id field of the
 +kvm_one_reg struct passed in. On success, the register value can be found
 +at the memory location pointed to by addr.
 +
 +The list of registers accessible using this interface is identical to the
 +list in 4.64.
 +
 5. The kvm_run structure
 
 Application code obtains a pointer to the kvm_run structure by
 diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
 index 76993eb..9c598b6 100644
 --- a/arch/powerpc/kvm/powerpc.c
 +++ b/arch/powerpc/kvm/powerpc.c
 @@ -214,6 +214,7 @@ int kvm_dev_ioctl_check_extension(long ext)
   case KVM_CAP_PPC_UNSET_IRQ:
   case KVM_CAP_PPC_IRQ_LEVEL:
   case KVM_CAP_ENABLE_CAP:
 + case KVM_CAP_ONE_REG:
   r = 1;
   break;
 #ifndef CONFIG_KVM_BOOK3S_64_HV
 @@ -642,6 +643,32 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu 
 *vcpu,
   return r;
 }
 
 +static int kvm_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_vcpu_ioctl_set_one_reg(struct kvm_vcpu *vcpu,
 +   struct kvm_one_reg *reg)
 +{
 + int r = -EINVAL;
 +
 + switch (reg-id) {
 + default:
 + break;
 + }
 +
 + return r;
 +}
 +
 int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
 struct kvm_mp_state *mp_state)
 {
 @@ -681,6 +708,30 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
   break;
   }
 
 + case KVM_GET_ONE_REG:
 + {
 + struct kvm_one_reg reg;
 + r = -EFAULT;
 + if (copy_from_user(reg, argp, sizeof(reg)))
 + goto out;
 + r = kvm_vcpu_ioctl_get_one_reg(vcpu, reg);
 + if (copy_to_user(argp, reg, sizeof(reg))) {
 + r =

Re: [PATCH V3 2/2] kvm tools: Create arch-specific kvm_cpu__emulate_{mm}io()

2012-01-05 Thread Matt Evans 
Hey Alex,

On 24/12/11 00:39, Alexander Graf wrote:
 
 On 23.12.2011, at 14:26, Matt Evans wrote:
 

 On 23/12/2011, at 11:58 PM, Alexander Graf wrote:


 On 13.12.2011, at 07:21, Matt Evans wrote:

 Different architectures will deal with MMIO exits differently.  For 
 example,
 KVM_EXIT_IO is x86-specific, and I/O cycles are often synthesised by 
 steering
 into windows in PCI bridges on other architectures.

 This patch calls arch-specific kvm_cpu__emulate_io() and 
 kvm_cpu__emulate_mmio()
 from the main runloop's IO and MMIO exit handlers.  For x86, these directly
 call kvm__emulate_io() and kvm__emulate_mmio() but other architectures will
 perform some address munging before passing on the call.

 Why do you need address munging? PIO is simply not there and MMIO always 
 goes to the physical address the CPU sees, so I don't see what you want to 
 munge. The way the memory bus is attached to the CPU should certainly not 
 be modeled differently for PPC and x86.

 PIO not there?  PIO is used heavily in kvmtool.  So, I made a window in a 
 similar way to how a real PHB has PIO-window-in-MMIO.

 PCI BARs are currently 32-bit.  I don't want to limit the guest RAM to 4G
 nor puncture holes in it just to make it look like x86... PCI bus addresses
 == CPU addresses is a bit of an x86ism.  So, I just used another PHB window
 to offset 32bit PCI MMIO up somewhere else.  We can then use all 4G of PCI
 MMIO space without putting that at addr 0 and RAM starting 4G.  (And then,
 exception vectors where?)

 The PCI/BARs/MMIO code could really support 64bit addresses though that's a
 bit of an orthogonal bit of work.  Why should PPC have an MMIO hole in the
 middle of RAM?
 

Sooo.. call it post-holiday bliss but I don't understand what you're saying
here. :)

 I fully agree with what you're saying, but the layering seems off. If the CPU
 gets an MMIO request, it gets that on a physical address from the view of the
   produces?

 CPU. Why would you want to have manual munging there to get to whatever window
 you have? Just map the MMIO regions to the higher addresses and expose
 whatever different representation you have to the device, not to the CPU
 layer.

What do you mean here by map and representation?  The only way I can parse
this is as though you're describing PCI devices seeing PCI bus addresses which
CPU MMIOs are converted to by the window offset, i.e. what already exists
i.e. what you're disagreeing with :-)

Sorry.. please explain some more.  Is your suggestion to make CPU phys addresses
and PCI bus addresses 1:1?  (Hole in RAM..)


Thanks!


Matt
--
To unsubscribe from this list: send the line unsubscribe kvm-ppc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html