Re: [Qemu-devel] [RFC] Next gen kvm api
On Tuesday 07 February 2012, Alexander Graf wrote: > >> > >> Not sure we'll ever get there. For PPC, it will probably take another 1-2 > >> years until we get the 32-bit targets stabilized. By then we will have new > >> 64-bit support though. And then the next gen will come out giving us even > >> more new constraints. > > > > I would expect that newer archs have less constraints, not more. > > Heh. I doubt it :). The 64-bit booke stuff is pretty similar to what we have > today on 32-bit, but extends a > bunch of registers to 64-bit. So what if we laid out stuff wrong before? > > I don't even want to imagine what v7 arm vs v8 arm looks like. It's a > completely new architecture. > I have not seen the source but I'm pretty sure that v7 and v8 they look very similar regarding virtualization support because they were designed together, including the concept that on v8 you can run either a v7 compatible 32 bit hypervisor with 32 bit guests or a 64 bit hypervisor with a combination of 32 and 64 bit guests. Also, the page table layout in v7-LPAE is identical to the v8 one. The main difference is the instruction set, but then ARMv7 already has four of these (ARM, Thumb, Thumb2, ThumbEE). Arnd -- 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] KVM: Add compat ioctl for KVM_SET_SIGNAL_MASK
On Tuesday 07 June 2011 22:25:15 Alexander Graf wrote:
> +static long kvm_vcpu_compat_ioctl(struct file *filp,
> + unsigned int ioctl, unsigned long arg)
> +{
> + struct kvm_vcpu *vcpu = filp->private_data;
> + void __user *argp = (void __user *)arg;
Converting a compat user argument into a pointer should use the
compat_ptr() function to do the right thing on s390. Otherwise
your patch looks good.
Arnd
--
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: [RFC][PATCH resend 8/12] asm-generic: bitops: introduce le bit offset macro
On Monday 10 May 2010, Takuya Yoshikawa wrote: > (2010/05/06 22:38), Arnd Bergmann wrote: > > On Wednesday 05 May 2010, Takuya Yoshikawa wrote: > >> There was a suggestion to propose set_le_bit_user() kind of macros. > >> But what I thought was these have a constraint you two explained and > >> seemed to be > >> a little bit specific to some area, like KVM. > >> > >> So I decided to propose just the offset calculation macro. > > > > I'm not sure I understand how this macro is going to be used though. > > If you are just using this in kernel space, that's fine, please go for > > it. > > Yes, I'm just using in kernel space: qemu has its own endian related helpers. > > So if you allow us to place this macro in asm-generic/bitops/* it will help > us. No problem at all then. Thanks for the explanation. Acked-by: Arnd Bergmann -- 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 14/27] Add book3s_64 specific opcode emulation
On Tuesday 03 November 2009, Benjamin Herrenschmidt wrote: > (Though glibc can be nasty, afaik it might load up optimized variants of > some routines with hard wired cache line sizes based on the CPU type) You can also get application with hand-coded cache optimizations that are even harder, if not impossible, to fix. Arnd <>< -- 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 00/27] Add KVM support for Book3s_64 (PPC64) hosts v5
On Wednesday 21 October 2009, Alexander Graf wrote: > > KVM for PowerPC only supports embedded cores at the moment. > > While it makes sense to virtualize on small machines, it's even more fun > to do so on big boxes. So I figured we need KVM for PowerPC64 as well. > > This patchset implements KVM support for Book3s_64 hosts and guest support > for Book3s_64 and G3/G4. > > To really make use of this, you also need a recent version of qemu. > > > Don't want to apply patches? Get the git tree! > > $ git clone git://csgraf.de/kvm > $ git checkout origin/ppc-v4 Whole series Acked-by: Arnd Bergmann Great work, Alex! Arnd <>< -- 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 26/27] Enable 32bit dirty log pointers on 64bit host
On Tuesday 29 September 2009, Avi Kivity wrote:
> >
> > r = -EINVAL;
> > if (log->slot >= KVM_MEMORY_SLOTS)
> > @@ -718,8 +719,15 @@ int kvm_get_dirty_log(struct kvm *kvm,
> > for (i = 0; !any && i < n/sizeof(long); ++i)
> > any = memslot->dirty_bitmap[i];
> >
> > +#if defined(__BIG_ENDIAN) && defined(CONFIG_64BIT)
> > + /* Need to convert user pointers */
> > + if (test_thread_flag(TIF_32BIT))
> > + target_bm = (void*)((u64)log->dirty_bitmap >> 32);
> > + else
> > +#endif
> > + target_bm = log->dirty_bitmap;
> > r = -EFAULT;
> > - if (copy_to_user(log->dirty_bitmap, memslot->dirty_bitmap, n))
> > + if (copy_to_user(target_bm, memslot->dirty_bitmap, n))
> > goto out;
> >
> > if (any)
>
> Ah, that's much better. Plus a mental note not to put pointers in
> user-visible structures in the future. This can serve as a reminder :)
It's still broken on s390, which
1. uses TIF_31BIT instead of TIF_32BIT
2. needs to call compat_ptr() to do a real conversion instead of a cast
The TIF_32BIT method is also not reliable. E.g. on x86_64 you are supposed
to get the 32 bit ABI when calling through INT80 instead of syscall/sysenter,
independent of the value of TIF_32BIT.
A better way to do this is to add a separate compat_ioctl() method that
converts this for you.
The patch below is an example for the canonical way to do this. Not tested!
Signed-off-by: Arnd Bergmann
---
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 897bff3..20f88ad 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2297,6 +2297,49 @@ out:
return r;
}
+#ifdef CONFIG_COMPAT
+struct compat_kvm_dirty_log {
+ __u32 slot;
+ __u32 padding1;
+ union {
+ compat_uptr_t dirty_bitmap; /* one bit per page */
+ __u64 padding2;
+ };
+};
+
+static long kvm_vm_compat_ioctl(struct file *filp,
+ unsigned int ioctl, unsigned long arg)
+{
+ struct kvm *kvm = filp->private_data;
+ int r;
+
+ if (kvm->mm != current->mm)
+ return -EIO;
+ switch (ioctl) {
+ case KVM_GET_DIRTY_LOG: {
+ struct compat_kvm_dirty_log compat_log;
+ struct kvm_dirty_log log;
+
+ r = -EFAULT;
+ if (copy_from_user(&compat_log, (void __user *)arg, sizeof log))
+ goto out;
+ log.slot = compat_log.slot;
+ log.padding1 = compat_log.padding1;
+ log.padding2 = compat_log.padding2;
+ log.dirty_bitmap = compat_ptr(compat_log.dirty_bitmap);
+
+ r = kvm_vm_ioctl_get_dirty_log(kvm, &log.log);
+ if (r)
+ goto out;
+ break;
+ default:
+ r = kvm_vm_ioctl(filp, ioctl, arg);
+ }
+
+ return r;
+}
+#endif
+
static int kvm_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
{
struct page *page[1];
@@ -2331,7 +2374,7 @@ static int kvm_vm_mmap(struct file *file, struct
vm_area_struct *vma)
static struct file_operations kvm_vm_fops = {
.release= kvm_vm_release,
.unlocked_ioctl = kvm_vm_ioctl,
- .compat_ioctl = kvm_vm_ioctl,
+ .compat_ioctl = kvm_vm_compat_ioctl,
.mmap = kvm_vm_mmap,
};
--
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 00/23] Add KVM support for PPC64 (970) hosts
On Tuesday 07 July 2009, Alexander Graf wrote: > KVM for PowerPC only supports embedded cores at the moment. > > While it makes sense to virtualize on small machines, it's even more fun > to do so on big boxes. So I figured we need KVM for PowerPC64 as well. Very nice to see how far you have come with this! > This patchset implements KVM support for PPC64 hosts and guest support > for PPC64 and G3/G4. Most of the code is after 970 but does look generic enough to be usable on other powerpc64 implementations. How specific to 970 is it really? Maybe the files and identifiers could be renamed to ppc64? You mentioned before that you could not get ppc32 guests to run on Cell hosts, but how about 970 or cell guests? Are there any problems that mean it cannot work on Power5/6/7 hosts, or was that just a matter of your priorities and available test hardware? Arnd <>< -- 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 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: > Dependent on the already existing CONFIG_KVM_GUEST config option this patch > changes wrteei to wrtee allowing the hypervisor to rewrite those to > nontrapping > instructions. Maybe we should split the kvm guest otpimizations in two parts > one for the overhead free optimizations and on for the rest that might add > some complexity for non virtualized execution (like this one). > > Signed-off-by: Christian Ehrhardt <[EMAIL PROTECTED]> How significant is the performance impact of this change for non-virtualized systems? If it's very low, maybe you should not bother with the #ifdef, and if it's noticable, you might be better off using dynamic patching for this. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
> +static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
> +{
> + register unsigned long hcall asm ("r0") = nr;
> + register unsigned long arg1 asm ("r3") = p1;
> + register long ret asm ("r11");
> +
> + asm volatile(".long %1"
> + : "=r"(ret)
> + : "i"(KVM_HYPERCALL_BIN), "r"(hcall), "r"(arg1)
> + : "r4", "r5", "r6", "r7", "r8",
> + "r9", "r10", "r12", "cc");
> + return ret;
> +}
What is the reasoning for making the calling convention different from
all the existing hcall interfaces here?
pseries uses r3 for the hcall number, lv1 and beat use r11, so using
r0 just for the sake of being different seems counterintuitive.
Arnd <><
