On 24/05/18 15:41, Jan Beulich wrote:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it is wrong to unconditionally zap the mapping
> when bringing down a CPU; it may only be unmap
Jan Beulich:
On 24.05.18 at 17:10, wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:14, wrote:
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact t
>>> On 24.05.18 at 17:10, wrote:
> Jan Beulich:
> On 24.05.18 at 16:14, wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs sha
>>> On 24.05.18 at 17:10, wrote:
> Jan Beulich:
> On 24.05.18 at 16:14, wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs sha
>>> On 24.05.18 at 16:18, wrote:
> Can you try with the "x86/traps: Dump the instruction stream even for
> double faults" patch I've just posted, and show the full #DF panic log
> please? (Its conceivable that there are multiple different issues here.)
Well, as long as we're on a guest kernel st
Andrew Cooper:
> On 24/05/18 15:35, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 24/05/18 15:14, Simon Gaiser wrote:
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to rem
Jan Beulich:
On 24.05.18 at 16:14, wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:00, wrote:
Jan Beulich:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it
> On May 24, 2018, at 3:53 PM, Andrew Cooper wrote:
>
> On 24/05/18 15:35, Simon Gaiser wrote:
>> Andrew Cooper:
>>> On 24/05/18 15:14, Simon Gaiser wrote:
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost al
On 24/05/18 15:35, Simon Gaiser wrote:
> Andrew Cooper:
>> On 24/05/18 15:14, Simon Gaiser wrote:
>>> Jan Beulich:
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that mult
Andrew Cooper:
> On 24/05/18 15:14, Simon Gaiser wrote:
>> Jan Beulich:
>> On 24.05.18 at 16:00, wrote:
Jan Beulich:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Ther
>>> On 24.05.18 at 16:24, wrote:
> On 24/05/18 15:22, Jan Beulich wrote:
> On 24.05.18 at 16:18, wrote:
>>> Can you try with the "x86/traps: Dump the instruction stream even for
>>> double faults" patch I've just posted, and show the full #DF panic log
>>> please? (Its conceivable that there
>>> On 24.05.18 at 16:14, wrote:
> Jan Beulich:
> On 24.05.18 at 16:00, wrote:
>>> Jan Beulich:
In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
I've failed to remember the fact that multiple CPUs share a stub
mapping page. Therefore it is wrong to uncondi
On 24/05/18 15:22, Jan Beulich wrote:
On 24.05.18 at 16:18, wrote:
>> Can you try with the "x86/traps: Dump the instruction stream even for
>> double faults" patch I've just posted, and show the full #DF panic log
>> please? (Its conceivable that there are multiple different issues here.)
>
On 24/05/18 15:14, Simon Gaiser wrote:
> Jan Beulich:
> On 24.05.18 at 16:00, wrote:
>>> Jan Beulich:
In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
I've failed to remember the fact that multiple CPUs share a stub
mapping page. Therefore it is wrong to un
Jan Beulich:
On 24.05.18 at 16:00, wrote:
>> Jan Beulich:
>>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>>> I've failed to remember the fact that multiple CPUs share a stub
>>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>>> when bringin
>>> On 24.05.18 at 16:00, wrote:
> Jan Beulich:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when bringing down a CPU; it ma
>>> On 24.05.18 at 15:48, wrote:
> On 24/05/18 14:41, Jan Beulich wrote:
>> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
>> I've failed to remember the fact that multiple CPUs share a stub
>> mapping page. Therefore it is wrong to unconditionally zap the mapping
>> when b
On 24/05/18 14:41, Jan Beulich wrote:
> In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
> I've failed to remember the fact that multiple CPUs share a stub
> mapping page. Therefore it is wrong to unconditionally zap the mapping
> when bringing down a CPU; it may only be unmap
In commit d1d6fc97d6 ("x86/xpti: really hide almost all of Xen image")
I've failed to remember the fact that multiple CPUs share a stub
mapping page. Therefore it is wrong to unconditionally zap the mapping
when bringing down a CPU; it may only be unmapped when no other online
CPU uses that same pa
19 matches
Mail list logo
