Re: [PATCH] kvm: x86/mmu: Fix is_tdp_mmu_check when using PAE

en using PAE. > > Tested: compiles > > Fixes: 02c00b3a2f7e ("kvm: x86/mmu: Allocate and free TDP MMU roots") > Reported-by: Zdenek Kaspar > Signed-off-by: Ben Gardon > --- > arch/x86/kvm/mmu/tdp_mmu.c | 10 ++ > 1 file changed, 10 insertions(+) > > dif

MDS/SSB Mitigation for pre-Nehalem/Older Intel Hardware?

Hello everyone, on old CPU the current situation looks like this: l1tf:Mitigation: PTE Inversion; VMX: EPT disabled mds:Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled meltdown:Mitigation: PTI spec_store_bypass:Vulnerable spectre_v1:Mitigation: __user pointer sanitization

Re: [PATCH 4.14 000/193] 4.14.3-stable review

On 11/28/2017 11:24 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.3 release. > There are 193 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 000/193] 4.14.3-stable review

On 11/28/2017 11:24 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.3 release. > There are 193 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH] KVM: VMX: require virtual NMI support

On 03/27/2017 02:38 PM, Paolo Bonzini wrote: > Virtual NMIs are only missing in Prescott and Yonah chips. Both are obsolete > for virtualization usage---Yonah is 32-bit only even---so drop vNMI emulation. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/vmx.c | 143 >

Re: [PATCH] KVM: VMX: require virtual NMI support

On 03/27/2017 02:38 PM, Paolo Bonzini wrote: > Virtual NMIs are only missing in Prescott and Yonah chips. Both are obsolete > for virtualization usage---Yonah is 32-bit only even---so drop vNMI emulation. > > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/vmx.c | 143 >

Re: [PATCH 4.1 125/159] net: call rcu_read_lock early in process_backlog

On 09/29/2015 12:48 PM, Andre Tomt wrote: > On 29. sep. 2015 12:21, Andre Tomt wrote: >> Meanwhile I'll revert both the mentioned net patches and see how it goes. > > So that blew up as well, meaning it's not any of these two patches: > [PATCH 4.1 124/159] net: do not process device backlog

Re: [PATCH 4.1 125/159] net: call rcu_read_lock early in process_backlog

On 09/29/2015 12:48 PM, Andre Tomt wrote: > On 29. sep. 2015 12:21, Andre Tomt wrote: >> Meanwhile I'll revert both the mentioned net patches and see how it goes. > > So that blew up as well, meaning it's not any of these two patches: > [PATCH 4.1 124/159] net: do not process device backlog

Re: SATA hdd refuses to reallocate a sector?

On 06/23/2013 12:19 PM, Pavel Machek wrote: > Hi! > > This may very well be hw problem, but... > > I have error on sda4. I tried to make hdd reallocate it by writing > zeros there, but it will not. Is there special kind of write that > needs to be done to force reallocation? Hi Pavel, maybe

Re: SATA hdd refuses to reallocate a sector?

On 06/23/2013 12:19 PM, Pavel Machek wrote: Hi! This may very well be hw problem, but... I have error on sda4. I tried to make hdd reallocate it by writing zeros there, but it will not. Is there special kind of write that needs to be done to force reallocation? Hi Pavel, maybe smartctl

Re: make tar*-pkg considered dangerous

On 09/12/2012 05:16 AM, Andi Kleen wrote: > > Hi, > > We've had some incidents with people destroying Fedore 17 installs > (to the point of reinstall) by installing a kernel tarball generated with > make tar*-pkg > > The problem is that the tarball includes /lib/{modules,firmware}, > but on

Re: [PATCH] Kbuild: use normal compression settings for tar*-pkg

On 09/08/2012 09:47 PM, Andi Kleen wrote: > From: Andi Kleen > > For large kernel configurations (like a distribution kernel) > targz-pkg takes a quite long time to just do the compression. > I clocked it at 15+mins for a SUSE kernel like config on a fast > system. And tarxz and bzip2 are even

Re: [PATCH] Kbuild: use normal compression settings for tar*-pkg

On 09/08/2012 09:47 PM, Andi Kleen wrote: From: Andi Kleen a...@linux.intel.com For large kernel configurations (like a distribution kernel) targz-pkg takes a quite long time to just do the compression. I clocked it at 15+mins for a SUSE kernel like config on a fast system. And tarxz and

Re: make tar*-pkg considered dangerous

On 09/12/2012 05:16 AM, Andi Kleen wrote: Hi, We've had some incidents with people destroying Fedore 17 installs (to the point of reinstall) by installing a kernel tarball generated with make tar*-pkg The problem is that the tarball includes /lib/{modules,firmware}, but on FC17 /lib

Re: Linux RAID subsystem future

On 07/12/2012 10:35 PM, NeilBrown wrote: > On Thu, 12 Jul 2012 13:28:24 -0700 Drew wrote: > >>> Hello lists, >>> >>> I noticed recent patches added MD RAID compatibility into the DM >>> subsystem. Is there a valid reason to duplicate efforts ? >>> >>> Hopefully its not silent preparation step

Re: Linux RAID subsystem future

On 07/12/2012 10:35 PM, NeilBrown wrote: On Thu, 12 Jul 2012 13:28:24 -0700 Drew drew@gmail.com wrote: Hello lists, I noticed recent patches added MD RAID compatibility into the DM subsystem. Is there a valid reason to duplicate efforts ? Hopefully its not silent preparation step for