linux-kernel - Re: [RFC PATCH v2 0/5] Paravirt Scheduling (Dynamic vcpu priority management)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240712130228.72de0a7d@rorschach.local.home>
Date: Fri, 12 Jul 2024 13:02:28 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Joel Fernandes
 <joel@...lfernandes.org>, Vineeth Remanan Pillai <vineeth@...byteword.org>,
 Ben Segall <bsegall@...gle.com>, Borislav Petkov <bp@...en8.de>, Daniel
 Bristot de Oliveira <bristot@...hat.com>, Dave Hansen
 <dave.hansen@...ux.intel.com>, Dietmar Eggemann <dietmar.eggemann@....com>,
 "H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>, Juri
 Lelli <juri.lelli@...hat.com>, Mel Gorman <mgorman@...e.de>, Paolo Bonzini
 <pbonzini@...hat.com>, Andy Lutomirski <luto@...nel.org>, Peter Zijlstra
 <peterz@...radead.org>, Thomas Gleixner <tglx@...utronix.de>, Valentin
 Schneider <vschneid@...hat.com>, Vincent Guittot
 <vincent.guittot@...aro.org>, Vitaly Kuznetsov <vkuznets@...hat.com>,
 Wanpeng Li <wanpengli@...cent.com>, Suleiman Souhlal <suleiman@...gle.com>,
 Masami Hiramatsu <mhiramat@...nel.org>, himadrics@...ia.fr,
 kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org,
 graf@...zon.com, drjunior.org@...il.com
Subject: Re: [RFC PATCH v2 0/5] Paravirt Scheduling (Dynamic vcpu priority
 management)

On Fri, 12 Jul 2024 09:39:52 -0700
Sean Christopherson <seanjc@...gle.com> wrote:

> > 
> > One other issue we need to worry about is that IIUC rseq memory is
> > allocated by the guest/user, not the host kernel. This means it can be
> > swapped out. The code that handles this needs to be able to handle user
> > page faults.  
> 
> This is a non-issue, it will Just Work, same as any other memory that is exposed
> to the guest and can be reclaimed/swapped/migrated..
> 
> If the host swaps out the rseq page, mmu_notifiers will call into KVM and KVM will
> unmap the page from the guest.  If/when the page is accessed by the guest, KVM
> will fault the page back into the host's primary MMU, and then map the new pfn
> into the guest.

My comment is that in the host kernel, the access to this memory needs
to be user page fault safe. You can't call it in atomic context.

-- Steve