From: kernel test robot <lkp@intel.com>
To: Alexander Graf <graf@amazon.com>
Cc: oe-kbuild-all@lists.linux.dev, kvm-ppc@vger.kernel.org
Subject: [agraf-2.6:kvm-kho-gmem-test 20/27] arch/arm64/kvm/mmu.c:1691:31: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'gfn_t' {aka 'long long unsigned int'}
Date: Sun, 5 May 2024 02:44:20 +0800 [thread overview]
Message-ID: <202405050218.bdbPXR1X-lkp@intel.com> (raw)
tree: https://github.com/agraf/linux-2.6.git kvm-kho-gmem-test
head: 9a58862a298a63bad21d05191e28b857063bb9dc
commit: dc3f33bb180826ee0bcd0ecc79cad842ff3ffccf [20/27] XXX early kvmm implementation
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20240505/202405050218.bdbPXR1X-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240505/202405050218.bdbPXR1X-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405050218.bdbPXR1X-lkp@intel.com/
All warnings (new ones prefixed by >>):
arch/arm64/kvm/mmu.c: In function 'kvm_handle_guest_abort':
>> arch/arm64/kvm/mmu.c:1691:31: warning: format '%lx' expects argument of type 'long unsigned int', but argument 4 has type 'gfn_t' {aka 'long long unsigned int'} [-Wformat=]
1691 | trace_printk("XXX %s:%d gfn=%lx memslot=%lx hva=%lx write_fault=%d\n", __func__, __LINE__, gfn, memslot, hva, write_fault);
| ~~^ ~~~
| | |
| long unsigned int gfn_t {aka long long unsigned int}
| %llx
>> arch/arm64/kvm/mmu.c:1691:43: warning: format '%lx' expects argument of type 'long unsigned int', but argument 5 has type 'struct kvm_memory_slot *' [-Wformat=]
1691 | trace_printk("XXX %s:%d gfn=%lx memslot=%lx hva=%lx write_fault=%d\n", __func__, __LINE__, gfn, memslot, hva, write_fault);
| ~~^ ~~~~~~~
| | |
| long unsigned int struct kvm_memory_slot *
vim +1691 arch/arm64/kvm/mmu.c
1613
1614 /**
1615 * kvm_handle_guest_abort - handles all 2nd stage aborts
1616 * @vcpu: the VCPU pointer
1617 *
1618 * Any abort that gets to the host is almost guaranteed to be caused by a
1619 * missing second stage translation table entry, which can mean that either the
1620 * guest simply needs more memory and we must allocate an appropriate page or it
1621 * can mean that the guest tried to access I/O memory, which is emulated by user
1622 * space. The distinction is based on the IPA causing the fault and whether this
1623 * memory region has been registered as standard RAM by user space.
1624 */
1625 int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
1626 {
1627 unsigned long esr;
1628 phys_addr_t fault_ipa;
1629 struct kvm_memory_slot *memslot;
1630 unsigned long hva;
1631 bool is_iabt, write_fault, writable;
1632 gfn_t gfn;
1633 int ret, idx;
1634
1635 esr = kvm_vcpu_get_esr(vcpu);
1636
1637 fault_ipa = kvm_vcpu_get_fault_ipa(vcpu);
1638 is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
1639
1640 if (esr_fsc_is_permission_fault(esr)) {
1641 /* Beyond sanitised PARange (which is the IPA limit) */
1642 if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
1643 kvm_inject_size_fault(vcpu);
1644 return 1;
1645 }
1646
1647 /* Falls between the IPA range and the PARange? */
1648 if (fault_ipa >= BIT_ULL(vcpu->arch.hw_mmu->pgt->ia_bits)) {
1649 fault_ipa |= kvm_vcpu_get_hfar(vcpu) & GENMASK(11, 0);
1650
1651 if (is_iabt)
1652 kvm_inject_pabt(vcpu, fault_ipa);
1653 else
1654 kvm_inject_dabt(vcpu, fault_ipa);
1655 return 1;
1656 }
1657 }
1658
1659 /* Synchronous External Abort? */
1660 if (kvm_vcpu_abt_issea(vcpu)) {
1661 /*
1662 * For RAS the host kernel may handle this abort.
1663 * There is no need to pass the error into the guest.
1664 */
1665 if (kvm_handle_guest_sea(fault_ipa, kvm_vcpu_get_esr(vcpu)))
1666 kvm_inject_vabt(vcpu);
1667
1668 return 1;
1669 }
1670
1671 trace_kvm_guest_fault(*vcpu_pc(vcpu), kvm_vcpu_get_esr(vcpu),
1672 kvm_vcpu_get_hfar(vcpu), fault_ipa);
1673
1674 /* Check the stage-2 fault is trans. fault or write fault */
1675 if (!esr_fsc_is_translation_fault(esr) &&
1676 !esr_fsc_is_permission_fault(esr) &&
1677 !esr_fsc_is_access_flag_fault(esr)) {
1678 kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
1679 kvm_vcpu_trap_get_class(vcpu),
1680 (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
1681 (unsigned long)kvm_vcpu_get_esr(vcpu));
1682 return -EFAULT;
1683 }
1684
1685 idx = srcu_read_lock(&vcpu->kvm->srcu);
1686
1687 gfn = fault_ipa >> PAGE_SHIFT;
1688 memslot = gfn_to_memslot(vcpu->kvm, gfn);
1689 hva = gfn_to_hva_memslot_prot(memslot, gfn, &writable);
1690 write_fault = kvm_is_write_fault(vcpu);
> 1691 trace_printk("XXX %s:%d gfn=%lx memslot=%lx hva=%lx write_fault=%d\n", __func__, __LINE__, gfn, memslot, hva, write_fault);
1692 if (kvm_is_error_hva(hva) || (write_fault && !writable)) {
1693 /*
1694 * The guest has put either its instructions or its page-tables
1695 * somewhere it shouldn't have. Userspace won't be able to do
1696 * anything about this (there's no syndrome for a start), so
1697 * re-inject the abort back into the guest.
1698 */
1699 if (is_iabt) {
1700 ret = -ENOEXEC;
1701 goto out;
1702 }
1703
1704 if (kvm_vcpu_abt_iss1tw(vcpu)) {
1705 kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
1706 ret = 1;
1707 goto out_unlock;
1708 }
1709
1710 /*
1711 * Check for a cache maintenance operation. Since we
1712 * ended-up here, we know it is outside of any memory
1713 * slot. But we can't find out if that is for a device,
1714 * or if the guest is just being stupid. The only thing
1715 * we know for sure is that this range cannot be cached.
1716 *
1717 * So let's assume that the guest is just being
1718 * cautious, and skip the instruction.
1719 */
1720 if (kvm_is_error_hva(hva) && kvm_vcpu_dabt_is_cm(vcpu)) {
1721 kvm_incr_pc(vcpu);
1722 ret = 1;
1723 goto out_unlock;
1724 }
1725
1726 /*
1727 * The IPA is reported as [MAX:12], so we need to
1728 * complement it with the bottom 12 bits from the
1729 * faulting VA. This is always 12 bits, irrespective
1730 * of the page size.
1731 */
1732 fault_ipa |= kvm_vcpu_get_hfar(vcpu) & ((1 << 12) - 1);
1733 ret = io_mem_abort(vcpu, fault_ipa);
1734 goto out_unlock;
1735 }
1736
1737 /* Userspace should not be able to register out-of-bounds IPAs */
1738 VM_BUG_ON(fault_ipa >= kvm_phys_size(vcpu->arch.hw_mmu));
1739
1740 if (esr_fsc_is_access_flag_fault(esr)) {
1741 handle_access_fault(vcpu, fault_ipa);
1742 ret = 1;
1743 goto out_unlock;
1744 }
1745
1746 ret = user_mem_abort(vcpu, fault_ipa, memslot, hva,
1747 esr_fsc_is_permission_fault(esr));
1748 if (ret == 0)
1749 ret = 1;
1750 out:
1751 if (ret == -ENOEXEC) {
1752 kvm_inject_pabt(vcpu, kvm_vcpu_get_hfar(vcpu));
1753 ret = 1;
1754 }
1755 out_unlock:
1756 srcu_read_unlock(&vcpu->kvm->srcu, idx);
1757 return ret;
1758 }
1759
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
reply other threads:[~2024-05-04 18:44 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=202405050218.bdbPXR1X-lkp@intel.com \
--to=lkp@intel.com \
--cc=graf@amazon.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
/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: link
Be 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 read-only IMAP folder(s) and NNTP newsgroup(s).