Thread (10 messages) 10 messages, 3 authors, 2013-09-17
DORMANTno replies
Revisions (3)
  1. v2 current
  2. v5 [diff vs current]
  3. v5 [diff vs current]

[PATCH v2 0/4] Target CPU=Host implementation for KVM ARM/ARM64

From: Christoffer Dall <hidden>
Date: 2013-09-17 21:10:09

On Sat, Sep 14, 2013 at 05:07:17PM +0530, Anup Patel wrote:
On Sat, Sep 14, 2013 at 4:38 PM, Anup Patel [off-list ref] wrote:
quoted
It will be very useful for user space if it has a method of querying
VCPU target type matching to underlying Host. We can use such querying
mechanism and implement machine models in user space where VCPU target
type is always same-as/similar-to underlying Host (i.e. Target CPU=Host).

This patch series implements KVM_ARM_PREFERRED_TARGET ioclt for querying
VCPU target type matching underlying host. Using this new ioctl we can
implement VCPU target CPU=Host in user space (i.e. QEMU/KVMTOOL).

Also, it is not mandatory to call KVM_ARM_PREFERRED_TARGET ioctl and the
old method of trying all possible target types using KVM_ARM_VCPU_INIT
ioctl to initialize VCPU works fine.

Anup Patel (4):
  ARM: KVM: Implement kvm_vcpu_preferred_target() function
  ARM64: KVM: Implement kvm_vcpu_preferred_target() function
  ARM/ARM64: KVM: Implement KVM_ARM_PREFERRED_TARGET ioctl
  KVM: Add documentation for KVM_ARM_PREFERRED_TARGET ioctl

 Documentation/virtual/kvm/api.txt |   26 ++++++++++++++++++++++----
 arch/arm/include/asm/kvm_host.h   |    1 +
 arch/arm/kvm/arm.c                |   12 ++++++++++++
 arch/arm/kvm/guest.c              |   19 +++++++++++++++++++
 arch/arm64/include/asm/kvm_host.h |    1 +
 arch/arm64/kvm/guest.c            |   20 ++++++++++++++++++++
 include/uapi/linux/kvm.h          |    1 +
 7 files changed, 76 insertions(+), 4 deletions(-)

--
1.7.9.5

_______________________________________________
kvmarm mailing list
kvmarm at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
Hi Christoffer,

I forgot to address two of your comments in this patch-series:
1. Make the IOCTL as VM IOCTL
2. Return ENODEV instead of EINVAL from IOCTL.

I will take care of the above in v3.
No worries, sorry for the delay in reviewing.

I'm wondering if we should actually make the ioctl a system ioctl
instead of a kvm ioctl so user space can just query the system about the
preferred target without having to create any KVM data structures.
Unless there's some problem with creating new system ioctls.  Anyone?

Assuming you take care of the above then this looks good!

Thanks,
-Christoffer
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help