On 03/15/2018 02:56 AM, Alexey Kardashevskiy wrote: > On 5/3/18 6:54 pm, Paul Mackerras wrote: >> This changes the hypervisor page fault handler for radix guests to use >> the generic KVM __gfn_to_pfn_memslot() function instead of using >> get_user_pages_fast() and then handling the case of VM_PFNMAP vmas >> specially. The old code missed the case of VM_IO vmas; with this >> change, VM_IO vmas will now be handled correctly by code within >> __gfn_to_pfn_memslot. >> >> Currently, __gfn_to_pfn_memslot calls hva_to_pfn, which only uses >> __get_user_pages_fast for the initial lookup in the cases where >> either atomic or async is set. Since we are not setting either >> atomic or async, we do our own __get_user_pages_fast first, for now. >> >> This also adds code to check for the KVM_MEM_READONLY flag on the >> memslot. If it is set and this is a write access, we synthesize a >> data storage interrupt for the guest. >> >> Signed-off-by: Paul Mackerras <paulus@xxxxxxxxxx> > > > This one produces multiple errors like this: > > Severe Machine check interrupt [Not recovered] > NIP [c008000005b34810]: 0xc008000005b34810 > Initiator: CPU > Error type: Real address [Load (bad)] > Effective address: c00c000080100284 > This is the same symptom for the XIVE ESBs. I have kept the workaround with hva_to_pfn_remapped() in kvmppc_book3s_radix_page_fault() for 4.16-rc6 Thanks, C. > 0xc008000005b34810 is a guest module, 0xc00c000080100284 is an MMIO address > (bar0 of a nvlink bridge). -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html