>>> On 01.02.16 at 18:31, wrote:
> On 01/02/16 16:51, Jan Beulich wrote:
> On 01.02.16 at 17:34, wrote:
>>> On 01/02/16 16:28, Jan Beulich wrote:
>>> On 01.02.16 at 15:07, wrote:
> On 01/02/16 13:20, Jan Beulich wrote:
>> Ping? (I'd really like to get this resolved, so we don't n
>>> On 01.02.16 at 18:31, wrote:
> On 01/02/16 16:51, Jan Beulich wrote:
> On 01.02.16 at 17:34, wrote:
>>> On 01/02/16 16:28, Jan Beulich wrote:
>>> On 01.02.16 at 15:07, wrote:
> On 01/02/16 13:20, Jan Beulich wrote:
>> Ping? (I'd really like to get this resolved, so we don't n
On 01/02/16 16:51, Jan Beulich wrote:
On 01.02.16 at 17:34, wrote:
>> On 01/02/16 16:28, Jan Beulich wrote:
>> On 01.02.16 at 15:07, wrote:
On 01/02/16 13:20, Jan Beulich wrote:
> Ping? (I'd really like to get this resolved, so we don't need to
> indefinitely run with non-up
>>> On 01.02.16 at 17:34, wrote:
> On 01/02/16 16:28, Jan Beulich wrote:
> On 01.02.16 at 15:07, wrote:
>>> On 01/02/16 13:20, Jan Beulich wrote:
Ping? (I'd really like to get this resolved, so we don't need to
indefinitely run with non-upstream behavior in our distros.)
>>> My rema
On 01/02/16 16:28, Jan Beulich wrote:
On 01.02.16 at 15:07, wrote:
>> On 01/02/16 13:20, Jan Beulich wrote:
>>> Ping? (I'd really like to get this resolved, so we don't need to
>>> indefinitely run with non-upstream behavior in our distros.)
>> My remaining issue is whether this loop gets exe
>>> On 01.02.16 at 15:07, wrote:
> On 01/02/16 13:20, Jan Beulich wrote:
>> Ping? (I'd really like to get this resolved, so we don't need to
>> indefinitely run with non-upstream behavior in our distros.)
>
> My remaining issue is whether this loop gets executed by default.
>
> I realise that th
On 01/02/16 13:20, Jan Beulich wrote:
> Ping? (I'd really like to get this resolved, so we don't need to
> indefinitely run with non-upstream behavior in our distros.)
>
> Thanks, Jan
My remaining issue is whether this loop gets executed by default.
I realise that there is a difference between le
Ping? (I'd really like to get this resolved, so we don't need to
indefinitely run with non-upstream behavior in our distros.)
Thanks, Jan
>>> On 13.01.16 at 17:15, wrote:
On 13.01.16 at 17:00, wrote:
>> On 13/01/16 15:36, Jan Beulich wrote:
>> On 13.01.16 at 16:25, wrote:
On 12/0
>>> On 13.01.16 at 17:00, wrote:
> On 13/01/16 15:36, Jan Beulich wrote:
> On 13.01.16 at 16:25, wrote:
>>> On 12/01/16 15:19, Jan Beulich wrote:
>>> On 12.01.16 at 12:55, wrote:
> On 12/01/16 10:08, Jan Beulich wrote:
>> This went unnoticed until a backport of this to an older X
On 13/01/16 15:36, Jan Beulich wrote:
On 13.01.16 at 16:25, wrote:
>> On 12/01/16 15:19, Jan Beulich wrote:
>> On 12.01.16 at 12:55, wrote:
On 12/01/16 10:08, Jan Beulich wrote:
> This went unnoticed until a backport of this to an older Xen got used,
> causing migration of g
>>> On 13.01.16 at 16:25, wrote:
> On 12/01/16 15:19, Jan Beulich wrote:
> On 12.01.16 at 12:55, wrote:
>>> On 12/01/16 10:08, Jan Beulich wrote:
This went unnoticed until a backport of this to an older Xen got used,
causing migration of guests enabling this VM assist to fail, becau
On 12/01/16 15:19, Jan Beulich wrote:
On 12.01.16 at 12:55, wrote:
>> On 12/01/16 10:08, Jan Beulich wrote:
>>> This went unnoticed until a backport of this to an older Xen got used,
>>> causing migration of guests enabling this VM assist to fail, because
>>> page table pinning there preceeds
>>> On 12.01.16 at 12:55, wrote:
> On 12/01/16 10:08, Jan Beulich wrote:
>> This went unnoticed until a backport of this to an older Xen got used,
>> causing migration of guests enabling this VM assist to fail, because
>> page table pinning there preceeds vCPU context loading, and hence L4
>> tabl
On 12/01/16 10:08, Jan Beulich wrote:
> This went unnoticed until a backport of this to an older Xen got used,
> causing migration of guests enabling this VM assist to fail, because
> page table pinning there preceeds vCPU context loading, and hence L4
> tables get initialized for the wrong mode. F
This went unnoticed until a backport of this to an older Xen got used,
causing migration of guests enabling this VM assist to fail, because
page table pinning there preceeds vCPU context loading, and hence L4
tables get initialized for the wrong mode. Fix this by post-processing
L4 tables when sett
15 matches
Mail list logo
