From: Avi Kivity <avi@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Ryan Harper <ryanh@us.ibm.com>, kvm@vger.kernel.org
Subject: Re: BUG at mmu.c:615 from localhost migration using ept+hugetlbfs
Date: Tue, 09 Jun 2009 19:47:10 +0300 [thread overview]
Message-ID: <4A2E920E.8010703@redhat.com> (raw)
In-Reply-To: <20090609164036.GA10828@amt.cnet>
Marcelo Tosatti wrote:
> Ryan,
>
> On Fri, May 29, 2009 at 11:43:26AM -0500, Ryan Harper wrote:
>
>> Testing latest qemu-kvm.git and kvm-kmod.git, ept enabled and backing
>> guests with large pages trips a BUG in the mmu code. If I disable ept,
>> but still use large pages, migration succeeds. Reproduce with:
>>
>> hugetlbfs setup:
>> % mkdir -p /hugetlbfs && mount -t hugetlbfs hugetlbfs /hugetlbfs
>> % echo 10000 > /proc/sys/vm/nr_hugepages
>>
>> qemu commands:
>>
>> guest a:
>> sudo x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 2048 -mempath /hugetlbfs -net nic -net tap -vnc :12 -monitor stdio -hda /scratch/images/rharper/rhel4u8-32-ide.raw
>>
>> guest b:
>> sudo x86_64-softmmu/qemu-system-x86_64 -L pc-bios -m 2048 -mempath /hugetlbfs -net nic -net tap -vnc :13 -monitor stdio -hda /scratch/images/rharper/rhel4u8-32-ide.raw -incoming tcp:0:4444
>>
>> Once the guest a is up, issued migrate command:
>> (qemu) migrate -d tcp:localhost:444
>>
>> rmap_remove: ffff880a08e00098 c0336e65c0336e5b 0->BUG
>>
> ^^^^^^^^^^^^^^^^
>
> This value looks very strange (bits 5:3 contain invalid value, for one).
> Don't have access to HW at the very moment, so it would be great if you
> had time to do a change equivalent to this and reproduce:
>
That spte is totally bogus.
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index 809cce0..ceb70b0 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -1759,7 +1764,7 @@ static void mmu_set_spte(struct kvm_vcpu *vcpu, u64 *shadow_pte,
> child = page_header(pte & PT64_BASE_ADDR_MASK);
> mmu_page_remove_parent_pte(child, shadow_pte);
> } else if (pfn != spte_to_pfn(*shadow_pte)) {
> - pgprintk("hfn old %lx new %lx\n",
> + printk(KERN_ERR "hfn old %lx new %lx\n",
> spte_to_pfn(*shadow_pte), pfn);
> rmap_remove(vcpu->kvm, shadow_pte);
> } else
>
> Avi, any hints?
>
Not really. One thing, migration should transition the shadow
pagetables from large pages to small ones, maybe that bit is broken.
Maybe we're looking at a largepage spte and interpreting it as a normal
L2 spte, and interpreting a guest page as the L1 spt.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-06-09 16:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 16:43 BUG at mmu.c:615 from localhost migration using ept+hugetlbfs Ryan Harper
2009-06-09 16:40 ` Marcelo Tosatti
2009-06-09 16:47 ` Avi Kivity [this message]
2009-06-10 8:08 ` Avi Kivity
2009-06-10 12:10 ` Marcelo Tosatti
2009-06-09 18:31 ` Ryan Harper
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=4A2E920E.8010703@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=ryanh@us.ibm.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