Hi George,
On 05/06/17 12:40, George Dunlap wrote:
On 24/05/17 17:57, Boris Ostrovsky wrote:
On 05/24/2017 06:21 AM, Jan Beulich wrote:
On 24.05.17 at 11:14, wrote:
Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
pages") left the NPT code untouched, as there is no explicit
On 24/05/17 17:57, Boris Ostrovsky wrote:
> On 05/24/2017 06:21 AM, Jan Beulich wrote:
> On 24.05.17 at 11:14, wrote:
>>> Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
>>> pages") left the NPT code untouched, as there is no explicit alignment
>>> check matching the one in
On 05/24/2017 06:21 AM, Jan Beulich wrote:
On 24.05.17 at 11:14, wrote:
>> Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
>> pages") left the NPT code untouched, as there is no explicit alignment
>> check matching the one in EPT code. However, the now more widespread
>> st
>>> On 24.05.17 at 11:14, wrote:
> Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
> pages") left the NPT code untouched, as there is no explicit alignment
> check matching the one in EPT code. However, the now more widespread
> storing of INVALID_MFN into PTEs requires adjustme
Commit efa9596e9d ("x86/mm: fix incorrect unmapping of 2MB and 1GB
pages") left the NPT code untouched, as there is no explicit alignment
check matching the one in EPT code. However, the now more widespread
storing of INVALID_MFN into PTEs requires adjustments:
- calculations when shattering large
