On Thu, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:22 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> >>On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >>>On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrot
On Thu, Feb 28, 2013 at 11:27:23AM -0500, Boris Ostrovsky wrote:
> What was the suggestion exactly? I don't remember seeing that message.
Use the paravirt patching facility to replace arch_flush_lazy_mmu_mode()
with a nop when running on baremetal. I.e., the whole functionality
around apply_paravi
On 02/28/2013 11:22 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
ca
On 02/28/2013 08:22 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
>> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
>>> On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COM
On Thu, Feb 28, 2013 at 11:20:20AM -0500, Boris Ostrovsky wrote:
> On 02/28/2013 11:10 AM, Borislav Petkov wrote:
> >On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> >>At the very least we should have an early filter for the **COMMON!**
> >>case that we are not on a PV platform.
>
On 02/28/2013 11:10 AM, Borislav Petkov wrote:
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
At the very least we should have an early filter for the **COMMON!**
case that we are not on a PV platform.
... or, patch it out with the alternatives on baremetal, as Steven
suggested
On Thu, Feb 28, 2013 at 07:53:44AM -0800, H. Peter Anvin wrote:
> At the very least we should have an early filter for the **COMMON!**
> case that we are not on a PV platform.
... or, patch it out with the alternatives on baremetal, as Steven
suggested.
--
Regards/Gruss,
Boris.
Sent from a
On 02/28/2013 07:38 AM, Borislav Petkov wrote:
> On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
>> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
>> index fb674fd..4f7d793 100644
>> --- a/arch/x86/mm/fault.c
>> +++ b/arch/x86/mm/fault.c
>> @@ -378,10 +378,12 @@ stati
On Thu, Feb 28, 2013 at 09:29:10AM -0500, Konrad Rzeszutek Wilk wrote:
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index fb674fd..4f7d793 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -378,10 +378,12 @@ static noinline __kprobes int vmalloc_fault(unsigned
> lon
On Wed, Feb 27, 2013 at 03:07:35PM -0800, H. Peter Anvin wrote:
> On 02/27/2013 03:00 PM, Greg KH wrote:
> >
> > "Stable" kernels are used all over the place, like in distros, which
> > might enable this.
> >
> > I have no objection to taking this patch in a stable release, as it does
> > fix a r
On 02/27/2013 03:00 PM, Greg KH wrote:
>
> "Stable" kernels are used all over the place, like in distros, which
> might enable this.
>
> I have no objection to taking this patch in a stable release, as it does
> fix a real problem.
>
OK. I will queue it up in the next fixes (tip:x86/urgent) ba
On Wed, Feb 27, 2013 at 02:40:01PM -0800, H. Peter Anvin wrote:
> Greg, policy opinion?
>
> -hpa
>
> On 02/26/2013 03:57 PM, Boris Ostrovsky wrote:
> >
> > - h...@zytor.com wrote:
> >
> >> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
> >>> When CONFIG_DEBUG_PAGEALLOC is set page tab
Greg, policy opinion?
-hpa
On 02/26/2013 03:57 PM, Boris Ostrovsky wrote:
>
> - h...@zytor.com wrote:
>
>> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
>>> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
>>> kernel_map_pages() are not made visible (via TLB flush) imm
- h...@zytor.com wrote:
> On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
> > When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> > kernel_map_pages() are not made visible (via TLB flush) immediately
> if lazy
> > MMU is on. In environments that support lazy MMU (e.g. Xen) this may
On 02/26/2013 02:56 PM, Boris Ostrovsky wrote:
> When CONFIG_DEBUG_PAGEALLOC is set page table updates made by
> kernel_map_pages() are not made visible (via TLB flush) immediately if lazy
> MMU is on. In environments that support lazy MMU (e.g. Xen) this may lead to
> fatal page faults, for exampl
15 matches
Mail list logo