Am 11.11.2015 um 18:30 schrieb Andrea Arcangeli: > Hi Jason, > > On Wed, Nov 11, 2015 at 10:35:16AM -0500, Jason J. Herne wrote: >> MADV_NOHUGEPAGE processing is too restrictive. kvm already disables >> hugepage but hugepage_madvise() takes the error path when we ask to turn >> on the MADV_NOHUGEPAGE bit and the bit is already on. This causes Qemu's > > I wonder why KVM disables transparent hugepages on s390. It sounds > weird to disable transparent hugepages with KVM. In fact on x86 we > call MADV_HUGEPAGE to be sure transparent hugepages are enabled on the > guest physical memory, even if the transparent_hugepage/enabled == > madvise. > >> new postcopy migration feature to fail on s390 because its first action is >> to madvise the guest address space as NOHUGEPAGE. This patch modifies the >> code so that the operation succeeds without error now. > > The other way is to change qemu to keep track it already called > MADV_NOHUGEPAGE and not to call it again. I don't have a strong > opinion on this, I think it's ok to return 0 but it's a visible change > to userland, I can't imagine it to break anything though. It sounds > very unlikely that an app could error out if it notices the kernel > doesn't error out on the second call of MADV_NOHUGEPAGE. > > Glad to hear KVM postcopy live migration is already running on s390 too.
Sometimes....we have some issues with userfaultd, which we currently address. One place is interesting: the kvm code might have to call fixup_user_fault for a guest address (to map the page writable). Right now we do not pass FAULT_FLAG_ALLOW_RETRY, which can trigger a warning like [ 119.414573] FAULT_FLAG_ALLOW_RETRY missing 1 [ 119.414577] CPU: 42 PID: 12853 Comm: qemu-system-s39 Not tainted 4.3.0+ #315 [ 119.414579] 000000011c4579b8 000000011c457a48 0000000000000002 0000000000000000 000000011c457ae8 000000011c457a60 000000011c457a60 0000000000113e26 00000000000002cf 00000000009feef8 0000000000a1e054 000000000000000b 000000011c457aa8 000000011c457a48 0000000000000000 0000000000000000 0000000000000000 0000000000113e26 000000011c457a48 000000011c457aa8 [ 119.414590] Call Trace: [ 119.414596] ([<0000000000113d16>] show_trace+0xf6/0x148) [ 119.414598] [<0000000000113dda>] show_stack+0x72/0xf0 [ 119.414600] [<0000000000551b9e>] dump_stack+0x6e/0x90 [ 119.414605] [<000000000032d168>] handle_userfault+0xe0/0x448 [ 119.414609] [<000000000029a2d4>] handle_mm_fault+0x16e4/0x1798 [ 119.414611] [<00000000002930be>] fixup_user_fault+0x86/0x118 [ 119.414614] [<0000000000126bb8>] gmap_ipte_notify+0xa0/0x170 [ 119.414617] [<000000000013ae90>] kvm_arch_vcpu_ioctl_run+0x448/0xc58 [ 119.414619] [<000000000012e4dc>] kvm_vcpu_ioctl+0x37c/0x668 [ 119.414622] [<00000000002eba68>] do_vfs_ioctl+0x3a8/0x508 [ 119.414624] [<00000000002ebc6c>] SyS_ioctl+0xa4/0xb8 [ 119.414627] [<0000000000815c56>] system_call+0xd6/0x264 [ 119.414629] [<000003ff9628721a>] 0x3ff9628721a I think we can rework this to use something that sets FAULT_FLAG_ALLOW_RETRY, but this begs the question if a futex operation on userfault backed memory would also be broken. The futex code also does fixup_user_fault without FAULT_FLAG_ALLOW_RETRY as far as I can tell. Christian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html