Prev: KVM: MMU: fix race between 'walk_addr' and 'fetch'
Next: stable? quality assurance?
From: Xiao Guangrong on 13 Jul 2010 00:30


Avi Kivity wrote:
> On 07/13/2010 04:16 AM, Xiao Guangrong wrote:
>>
>>
>>> btw, what about dirty logging? will prefetch cause pages to be marked
>>> dirty?
>>>
>>> We may need to instantiate prefetched pages with spte.d=0 and examine it
>>> when tearing down the spte.
>>>
>>>
>> Yeah, all speculative path are broken dirty bit tracking, and i guess
>> it's
>> need more review, so i plan to do it in the separate patch, i'll post
>> it after
>> this patchset merged, could you allow it?
>>
>>
>
> Regressions? no. Or do you mean the problem already exists? Where?

I mean this is a exist problem, likes invlpg, pte-write and sync-page, there are
speculative path that it's not real access, but marked dirty if pte is writable.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 13 Jul 2010 01:40
On 07/13/2010 07:25 AM, Xiao Guangrong wrote:
>
>> Regressions? no. Or do you mean the problem already exists? Where?
>>
> I mean this is a exist problem, likes invlpg, pte-write and sync-page, there are
> speculative path that it's not real access, but marked dirty if pte is writable.
>

Right. We should fix those too.

Prefetch is much more worrying though, especially with ept. If a guest
is using just 1/8 of the pages, it can look to migration as if it's
using 100% of the pages. The impact can be pretty large.

In contrast, I'm not too worried about invlpg, as most times an access
will follow a miss, and usually a write access if we set a writeable
pte. Not sure about sync-page.

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Xiao Guangrong on 13 Jul 2010 02:00


Avi Kivity wrote:
> On 07/13/2010 07:25 AM, Xiao Guangrong wrote:
>>
>>> Regressions? no. Or do you mean the problem already exists? Where?
>>>
>> I mean this is a exist problem, likes invlpg, pte-write and sync-page,
>> there are
>> speculative path that it's not real access, but marked dirty if pte is
>> writable.
>>
>
> Right. We should fix those too.
>
> Prefetch is much more worrying though, especially with ept. If a guest
> is using just 1/8 of the pages, it can look to migration as if it's
> using 100% of the pages. The impact can be pretty large.

We disabled prefetch if ept is enabled since it can break access bit tracking.

I'll fix the dirty bit tracking before post the new version of this patchset.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 13 Jul 2010 02:10
On 07/13/2010 08:48 AM, Xiao Guangrong wrote:
>
>> Right. We should fix those too.
>>
>> Prefetch is much more worrying though, especially with ept. If a guest
>> is using just 1/8 of the pages, it can look to migration as if it's
>> using 100% of the pages. The impact can be pretty large.
>>
> We disabled prefetch if ept is enabled since it can break access bit tracking.
>

Oh yes.

> I'll fix the dirty bit tracking before post the new version of this patchset.
>

Should be simple - disable prefetch for slots that have dirty tracking
enabled.

What about the Linux accessed and dirty bits? Need to instantiate the
speculative sptes with accessed and dirty bits clear (and later examine
them when we release the page).

--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Xiao Guangrong on 13 Jul 2010 02:20


Avi Kivity wrote:
> On 07/13/2010 08:48 AM, Xiao Guangrong wrote:
>>
>>> Right. We should fix those too.
>>>
>>> Prefetch is much more worrying though, especially with ept. If a guest
>>> is using just 1/8 of the pages, it can look to migration as if it's
>>> using 100% of the pages. The impact can be pretty large.
>>>
>> We disabled prefetch if ept is enabled since it can break access bit
>> tracking.
>>
>
> Oh yes.
>
>> I'll fix the dirty bit tracking before post the new version of this
>> patchset.
>>
>
> Should be simple - disable prefetch for slots that have dirty tracking
> enabled.

Agree.

>
> What about the Linux accessed and dirty bits? Need to instantiate the
> speculative sptes with accessed and dirty bits clear (and later examine
> them when we release the page).
>

I see, will do :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: KVM: MMU: fix race between 'walk_addr' and 'fetch'
Next: stable? quality assurance?