On Wed, Aug 27, 2008 at 06:50:27PM +0300, Avi Kivity wrote:
> Joerg Roedel wrote:
> >On Wed, Aug 27, 2008 at 06:22:14PM +0300, Avi Kivity wrote:
> >
> >>Joerg Rodel wrote:
> >>
> >>>I will test it. Is the fix in your latest kernel.org tree?
> >>It is now. It doesn't fix the problem.
> >>
> >>
> >>>Reproduce it
> >>>with a KVM guest and start tbench in it with around 100 clients
> >>>configured. The tbench-process will crash when the bug is hit.
> >>>
> >>Does it reproduce with uniprocessor guests?
> >>
> >
> >Don't know yet. We will try that.
> >
> >
>
> It didn't reproduce here on uniprocessor, but I hadn't tried for long.
We are still testing. In the moment it does not reproduce very fast, for
whatever reason...
>
> Some observations:
>
> - tbench triggers many cases where we have concurrent faults on the same
> address.
> these are serialized by mmu_lock. I tried to have direct_map_entry() return
> is
> it detects a race. didn't help.
> - I instrumented set_shadow_pte() to warn if changing the pfn or writeable
> bit.
> Didn't trip.
>
> Are there any rules for touching npt ptes concurrently?
Hmm, not that I am aware of. I will ask the silicon guys if they know
something. But I don't think so.
> Meanwhile, I applied the patch, but I'm very worried about this.
Yes, we are also worried. Another question is why this only happens with
NPT. The SoftMMU code should also fail with shadow paging if there is a
bug.
Joerg
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
