Ahmed,
On Fri, 2018-12-07 at 14:47 +0200, Ahmed Abd El Mawgood wrote:
> The reason why it would be better to implement this from inside kvm: instead
> of
> (host) user space is the need to access SPTEs to modify the permissions, while
> mprotect() from user space can work in theory. It will
On Mon, 2018-10-29 at 10:26 -0700, Sean Christopherson wrote:
> I think it's a good idea to explicitly call out that clearing the
> GPRs
> is done to prevent speculative use. Simply stating that we don't
> want
> to let guest register values survive doesn't explain *why*.
>
> What about:
>
>
On Mon, 2018-10-29 at 10:26 -0700, Sean Christopherson wrote:
> I think it's a good idea to explicitly call out that clearing the
> GPRs
> is done to prevent speculative use. Simply stating that we don't
> want
> to let guest register values survive doesn't explain *why*.
>
> What about:
>
>
On Fri, 2018-10-26 at 09:30 -0700, Jim Mattson wrote:
> On Fri, Oct 26, 2018 at 8:46 AM, Sean Christopherson
> wrote:
>
> > And FWIW, I find the original code to be more readable since all
> > GRPs
> > are zeroed with the same method.
> I concur. I really do prefer the explicit xors to the input
On Fri, 2018-10-26 at 09:30 -0700, Jim Mattson wrote:
> On Fri, Oct 26, 2018 at 8:46 AM, Sean Christopherson
> wrote:
>
> > And FWIW, I find the original code to be more readable since all
> > GRPs
> > are zeroed with the same method.
> I concur. I really do prefer the explicit xors to the input
On Wed, 2018-10-24 at 10:44 -0700, Eric Northup wrote:
> This loses the exception handling from __ex* ->
> kvm_handle_fault_on_reboot.
>
> If deliberate, this should be called out in changelog. Has the race
> which commit 4ecac3fd fixed been mitigated otherwise?
No, this was not deliberate.
On Wed, 2018-10-24 at 10:44 -0700, Eric Northup wrote:
> This loses the exception handling from __ex* ->
> kvm_handle_fault_on_reboot.
>
> If deliberate, this should be called out in changelog. Has the race
> which commit 4ecac3fd fixed been mitigated otherwise?
No, this was not deliberate.
On Thu, 2018-10-25 at 09:55 -0700, Jim Mattson wrote:
> Looking at the second asm statement and the comment that precedes it,
> my first question would be, "What about the registers not covered
> here?"
Good point. I'll make the comment a bit clearer.
> I'm also not convinced that the
On Thu, 2018-10-25 at 09:55 -0700, Jim Mattson wrote:
> Looking at the second asm statement and the comment that precedes it,
> my first question would be, "What about the registers not covered
> here?"
Good point. I'll make the comment a bit clearer.
> I'm also not convinced that the
On Sun, 2018-09-23 at 12:33 +1000, Balbir Singh wrote:
> > And in so doing, significantly reduces the amount of non-kernel
> data
> > vulnerable to speculative execution attacks against the kernel.
> > (and reduces what data can be loaded into the L1 data cache while
> > in kernel mode, to be
On Sun, 2018-09-23 at 12:33 +1000, Balbir Singh wrote:
> > And in so doing, significantly reduces the amount of non-kernel
> data
> > vulnerable to speculative execution attacks against the kernel.
> > (and reduces what data can be loaded into the L1 data cache while
> > in kernel mode, to be
On Tue, 2018-09-18 at 17:00 -0600, Khalid Aziz wrote:
> I tested the kernel with this new code. When booted without
> "xpfotlbflush",
> there is no meaningful change in system time with kernel compile.
That's good news! So the lock optimizations seem to help.
> Kernel
> locks up during bootup
On Tue, 2018-09-18 at 17:00 -0600, Khalid Aziz wrote:
> I tested the kernel with this new code. When booted without
> "xpfotlbflush",
> there is no meaningful change in system time with kernel compile.
That's good news! So the lock optimizations seem to help.
> Kernel
> locks up during bootup
13 matches
Mail list logo
