From: James Hogan <james.hogan@imgtec.com> To: <jiang.biao2@zte.com.cn> Cc: <linux-mips@linux-mips.org>, <pbonzini@redhat.com>, <rkrcmar@redhat.com>, <ralf@linux-mips.org>, <kvm@vger.kernel.org> Subject: Re: [PATCH 2/13] KVM: MIPS: Pass type of fault down to kvm_mips_map_page() Date: Tue, 17 Jan 2017 13:27:49 +0000 [thread overview] Message-ID: <20170117132749.GA11733@jhogan-linux.le.imgtec.org> (raw) In-Reply-To: <201701171906397244491@zte.com.cn> [-- Attachment #1: Type: text/plain, Size: 3196 bytes --] Hi, On Tue, Jan 17, 2017 at 07:06:39PM +0800, jiang.biao2@zte.com.cn wrote: > > kvm_mips_map_page() will need to know whether the fault was due to a > > read or a write in order to support dirty page tracking, > > KVM_CAP_SYNC_MMU, and read only memory regions, so get that information > > passed down to it via new bool write_fault arguments to various > > functions. > > Hi, James, > > > Maybe it's not good idea to add an argument and pass it down to various functions, it will , > > make the the interface more complicated, have more possibolity, and more difficult to test. > kvm_mips_map_page() needs to know is whether it is being triggered in response to a write, but it is abstracted and independent from what host exception triggered it. It is only really concerned with the GPA space. > > > > As far as I can see, what you need is to let kvm_mips_map_page() know the *reason*. > > would it be better to let kvm_mips_map_page() get *exccode* from the CP0 directly, or > > > provide any interface to get the fault reason? I presume you mean from the saved host cause register in the VCPU context (since intervening exceptions/interrupts will clobber the actual CP0 Cause register). It directly needs to know whether it can get away with a read-only mapping, and although it directly depends on a GVA segment, it doesn't necessarily relate to a memory access made by the guest. kvm_mips_map_page() is called via: - kvm_mips_handle_kseg0_tlb_fault() for faults in guest KSeg0 - kvm_mips_handle_mapped_seg_tlb_fault() for faults in guest TLB mapped segments From these functions: - kvm_trap_emul_handle_tlb_mod() (write_fault = true) in response to a write to a read-only page (exccode = MOD) - kvm_trap_emul_handle_tlb_miss() (write_fault = true or false) in response to a read or write when TLB mapping absent or invalid (exccode = TLBL/TLBS) - via the kvm_trap_emul_gva_fault() helper when KVM needs to directly access GVA space: - kvm_get_inst() (write_fault = false) when reading an instruction from guest RAM (when BadInstr/BadInstrP registers unavailable) which needs to be emulated, i.e. reserved instruction (exccode = RI), cop0 unusuable (exccode = CPU), MMIO load/store (TLBL/TLBS/MOD/ADEL/ADES), branch delay slot handling for MMIO load/store, or debug output for an unhandled exccode (exccode = ?) - kvm_mips_trans_replace() (write_fault = true) to write a replacement instruction into guest memory (mainly exccode = CPU) - kvm_mips_guest_cache_op() (write_fault = false) cache instruction emulation (exccode = CPU) So there is a many:many mapping from exccode to write_fault for these exccodes: - CPU (CoProcessor Unusable) could be reading instruction or servicing a CACHE instruction (write_fault = false) or replacing an instruction (write_fault = true). - MOD, TLBS, ADES could be the write itself (write_fault = true), or a read of the instruction triggering the exception or the prior branch instruction (write_fault = false). Cheers James [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com> To: jiang.biao2@zte.com.cn Cc: linux-mips@linux-mips.org, pbonzini@redhat.com, rkrcmar@redhat.com, ralf@linux-mips.org, kvm@vger.kernel.org Subject: Re: [PATCH 2/13] KVM: MIPS: Pass type of fault down to kvm_mips_map_page() Date: Tue, 17 Jan 2017 13:27:49 +0000 [thread overview] Message-ID: <20170117132749.GA11733@jhogan-linux.le.imgtec.org> (raw) Message-ID: <20170117132749.Le07xp6nD3tQoACDC3zv0GYfRDSHGEQRSqJDePp93IA@z> (raw) In-Reply-To: <201701171906397244491@zte.com.cn> [-- Attachment #1: Type: text/plain, Size: 3196 bytes --] Hi, On Tue, Jan 17, 2017 at 07:06:39PM +0800, jiang.biao2@zte.com.cn wrote: > > kvm_mips_map_page() will need to know whether the fault was due to a > > read or a write in order to support dirty page tracking, > > KVM_CAP_SYNC_MMU, and read only memory regions, so get that information > > passed down to it via new bool write_fault arguments to various > > functions. > > Hi, James, > > > Maybe it's not good idea to add an argument and pass it down to various functions, it will , > > make the the interface more complicated, have more possibolity, and more difficult to test. > kvm_mips_map_page() needs to know is whether it is being triggered in response to a write, but it is abstracted and independent from what host exception triggered it. It is only really concerned with the GPA space. > > > > As far as I can see, what you need is to let kvm_mips_map_page() know the *reason*. > > would it be better to let kvm_mips_map_page() get *exccode* from the CP0 directly, or > > > provide any interface to get the fault reason? I presume you mean from the saved host cause register in the VCPU context (since intervening exceptions/interrupts will clobber the actual CP0 Cause register). It directly needs to know whether it can get away with a read-only mapping, and although it directly depends on a GVA segment, it doesn't necessarily relate to a memory access made by the guest. kvm_mips_map_page() is called via: - kvm_mips_handle_kseg0_tlb_fault() for faults in guest KSeg0 - kvm_mips_handle_mapped_seg_tlb_fault() for faults in guest TLB mapped segments From these functions: - kvm_trap_emul_handle_tlb_mod() (write_fault = true) in response to a write to a read-only page (exccode = MOD) - kvm_trap_emul_handle_tlb_miss() (write_fault = true or false) in response to a read or write when TLB mapping absent or invalid (exccode = TLBL/TLBS) - via the kvm_trap_emul_gva_fault() helper when KVM needs to directly access GVA space: - kvm_get_inst() (write_fault = false) when reading an instruction from guest RAM (when BadInstr/BadInstrP registers unavailable) which needs to be emulated, i.e. reserved instruction (exccode = RI), cop0 unusuable (exccode = CPU), MMIO load/store (TLBL/TLBS/MOD/ADEL/ADES), branch delay slot handling for MMIO load/store, or debug output for an unhandled exccode (exccode = ?) - kvm_mips_trans_replace() (write_fault = true) to write a replacement instruction into guest memory (mainly exccode = CPU) - kvm_mips_guest_cache_op() (write_fault = false) cache instruction emulation (exccode = CPU) So there is a many:many mapping from exccode to write_fault for these exccodes: - CPU (CoProcessor Unusable) could be reading instruction or servicing a CACHE instruction (write_fault = false) or replacing an instruction (write_fault = true). - MOD, TLBS, ADES could be the write itself (write_fault = true), or a read of the instruction triggering the exception or the prior branch instruction (write_fault = false). Cheers James [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --]
next parent reply other threads:[~2017-01-17 13:28 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <201701171906397244491@zte.com.cn> 2017-01-17 13:27 ` James Hogan [this message] 2017-01-17 13:27 ` [PATCH 2/13] KVM: MIPS: Pass type of fault down to kvm_mips_map_page() James Hogan [not found] <201701191629518310684@zte.com.cn> 2017-01-19 9:08 ` James Hogan 2017-01-19 9:08 ` James Hogan [not found] <201701181618464411994@zte.com.cn> 2017-01-18 12:12 ` James Hogan 2017-01-18 12:12 ` James Hogan 2017-01-16 12:49 [PATCH 0/13] KVM: MIPS: Dirty logging, SYNC_MMU & READONLY_MEM James Hogan 2017-01-16 12:49 ` [PATCH 2/13] KVM: MIPS: Pass type of fault down to kvm_mips_map_page() James Hogan 2017-01-16 12:49 ` James Hogan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170117132749.GA11733@jhogan-linux.le.imgtec.org \ --to=james.hogan@imgtec.com \ --cc=jiang.biao2@zte.com.cn \ --cc=kvm@vger.kernel.org \ --cc=linux-mips@linux-mips.org \ --cc=pbonzini@redhat.com \ --cc=ralf@linux-mips.org \ --cc=rkrcmar@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).