From: Joerg Roedel <joro@8bytes.org>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: "Roedel, Joerg" <Joerg.Roedel@amd.com>, kvm <kvm@vger.kernel.org>,
Sheng Yang <sheng@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Crash on kvm_iommu_map_pages
Date: Mon, 1 Nov 2010 15:35:26 +0100 [thread overview]
Message-ID: <20101101143526.GD2987@8bytes.org> (raw)
In-Reply-To: <4CCECD17.3080303@web.de>
On Mon, Nov 01, 2010 at 03:22:15PM +0100, Jan Kiszka wrote:
> Am 01.11.2010 14:53, Roedel, Joerg wrote:
> > On Mon, Nov 01, 2010 at 09:25:00AM -0400, Jan Kiszka wrote:
> >> Am 01.11.2010 14:21, Roedel, Joerg wrote:
> >>> The registers rax and rbx contain non-canonical addresses (if
> >>> interpreted as pointers). The instruction where this happens is a mov so
> >>> I guess that the #GP is because of an non-canonical address.
> >>> Can you find out the code-line where this happens and the exact
> >>> assembler instruction? (haven't managed to decode the registers used).
> >>
> >> In pfn_to_dma_pte, line 710:
> >>
> >> if (!dma_pte_present(pte)) {
> >> ffffffff8121de8c: f6 03 03 testb $0x3,(%rbx)
> >> ffffffff8121de8f: 0f 85 d8 00 00 00 jne ffffffff8121df6d <pfn_to_dma_pte+0x154>
> >>
> >> The first instruction raises the fault.
> >
> > Ok, so it seems that my understanding of the Code: field in the
> > crash-message was wrong :)
> > Anyway, the testb uses rbx as an address which has a non-canonical
> > value. This means the the address of 'pte' is invalid. Since rax also
> > contains a wrong address the 'parent' variable probably already contains
> > the wrong address. Does the attached patch help?
> >
> > diff --git a/include/linux/dma_remapping.h b/include/linux/dma_remapping.h
> > index 5619f85..ca46f24 100644
> > --- a/include/linux/dma_remapping.h
> > +++ b/include/linux/dma_remapping.h
> > @@ -6,7 +6,7 @@
> > */
> > #define VTD_PAGE_SHIFT (12)
> > #define VTD_PAGE_SIZE (1UL << VTD_PAGE_SHIFT)
> > -#define VTD_PAGE_MASK (((u64)-1) << VTD_PAGE_SHIFT)
> > +#define VTD_PAGE_MASK ((((u64)-1) << VTD_PAGE_SHIFT) & ((1ULL << 52) - 1))
> > #define VTD_PAGE_ALIGN(addr) (((addr) + VTD_PAGE_SIZE - 1) & VTD_PAGE_MASK)
> >
> > #define DMA_PTE_READ (1)
> >
>
> Crashes during early boot while initializing dmar. If you need the
> trace, I could set up some debug console.
Hmm, no. This was only a guess. The VTD_PAGE_MASK does not mask out the
bits 52-63 of the pte. According to the VT-d spec it is allowed to set
these bits, some are marked as AVL and some have special meanings. If a
pte has one of these bits set the phys_addr calculated will be wrong and
the virt_addr calculated from it too (probably non-canonical, leading to
the GPF).
Probably masking out these bits in dma_pte_addr helps.
Joerg
next prev parent reply other threads:[~2010-11-01 14:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-01 12:51 Crash on kvm_iommu_map_pages Jan Kiszka
2010-11-01 12:57 ` Jan Kiszka
2010-11-01 13:21 ` Roedel, Joerg
2010-11-01 13:25 ` Jan Kiszka
2010-11-01 13:53 ` Roedel, Joerg
2010-11-01 14:22 ` Jan Kiszka
2010-11-01 14:35 ` Joerg Roedel [this message]
2010-11-01 15:29 ` Jan Kiszka
2010-11-01 16:37 ` Jan Kiszka
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=20101101143526.GD2987@8bytes.org \
--to=joro@8bytes.org \
--cc=Joerg.Roedel@amd.com \
--cc=jan.kiszka@web.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sheng@linux.intel.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: 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 NNTP newsgroup(s).