On Thu, Jun 4, 2020 at 3:37 PM Marc Zyngier wrote:
> > I have an issue on one particular hardware with gicv3 and the old
> > stable (4.9.22x) kernel where the timer interrupt randomly leaks to
> > the host after the guest exit and the kvm_arch_timer_handler gets
> > triggered. The guest does
On Mon, Jun 08, 2020 at 04:42:42PM +0100, Marc Zyngier wrote:
> Hi Andrew,
>
> On 2020-06-08 15:51, Andrew Scull wrote:
> > On Mon, Jun 08, 2020 at 09:56:57AM +0100, Marc Zyngier wrote:
> > > For very long, we have kept this pointer back to the per-cpu
> > > host state, despite having working
On Mon, Jun 08, 2020 at 09:57:31AM +0100, Marc Zyngier wrote:
> Sparse complains that __hyp_this_cpu_ptr() returns something
> that is flagged noderef and not in the correct address space
> (both being the result of the __percpu annotation).
>
> Pretend that __hyp_this_cpu_ptr() knows what it is
On Mon, Jun 08, 2020 at 09:56:57AM +0100, Marc Zyngier wrote:
> For very long, we have kept this pointer back to the per-cpu
> host state, despite having working per-cpu accessors at EL2
> for some time now.
>
> Recent investigations have shown that this pointer is easy
> to abuse in preemptible
Hi Eric,
On 2020-06-08 17:58, Auger Eric wrote:
Hi Marc,
On 5/26/20 6:11 PM, Marc Zyngier wrote:
On a system that uses SPIs to implement MSIs (as it would be
the case on a GICv2 system exposing a GICv2m to its guests),
we deny the possibility of injecting SPIs on the in-atomic
fast-path.
Hi Marc,
On 5/26/20 6:11 PM, Marc Zyngier wrote:
> On a system that uses SPIs to implement MSIs (as it would be
> the case on a GICv2 system exposing a GICv2m to its guests),
> we deny the possibility of injecting SPIs on the in-atomic
> fast-path.
>
> This results in a very large amount of
On 2020-06-08 16:00, Andrew Scull wrote:
On Mon, Jun 08, 2020 at 09:57:31AM +0100, Marc Zyngier wrote:
Sparse complains that __hyp_this_cpu_ptr() returns something
that is flagged noderef and not in the correct address space
(both being the result of the __percpu annotation).
Pretend that
On Mon, Jun 08, 2020 at 09:56:57AM +0100, Marc Zyngier wrote:
> For very long, we have kept this pointer back to the per-cpu
> host state, despite having working per-cpu accessors at EL2
> for some time now.
>
> Recent investigations have shown that this pointer is easy
> to abuse in preemptible
Hi Andrew,
On 2020-06-08 15:51, Andrew Scull wrote:
On Mon, Jun 08, 2020 at 09:56:57AM +0100, Marc Zyngier wrote:
For very long, we have kept this pointer back to the per-cpu
host state, despite having working per-cpu accessors at EL2
for some time now.
Recent investigations have shown that
On Mon, 8 Jun 2020 16:28:01 +0100, Marc Zyngier wrote:
> Recent changes made to Linux 5.8 have outlined that kvmtool
> hardcodes the text offset instead of reading it from the arm64
> image itself.
>
> To address this, import the image header structure into kvmtool
> and do the right thing. 32bit
Recent changes made to Linux 5.8 have outlined that kvmtool
hardcodes the text offset instead of reading it from the arm64
image itself.
To address this, import the image header structure into kvmtool
and do the right thing. 32bit guests are still loaded to their
usual locations.
While we're at
Reviewed-by: Huacai Chen
On Sat, Jun 6, 2020 at 5:44 AM Sean Christopherson
wrote:
>
> Replace the @max param in mmu_topup_memory_cache() and instead use
> ARRAY_SIZE() to terminate the loop to fill the cache. This removes a
> BUG_ON() and sets the stage for moving MIPS to the common memory
Reviewed-by: Huacai Chen
On Sat, Jun 6, 2020 at 5:41 AM Sean Christopherson
wrote:
>
> Move to the common MMU memory cache implementation now that the common
> code and MIPS's existing code are semantically compatible.
>
> No functional change intended.
>
> Suggested-by: Christoffer Dall
>
Reviewed-by: Huacai Chen
On Sat, Jun 6, 2020 at 5:40 AM Sean Christopherson
wrote:
>
> Use GFP_KERNEL_ACCOUNT instead of GFP_KERNEL when allocating pages for
> the the GPA page tables. The primary motivation for accounting the
> allocations is to align with the common KVM memory cache helpers
Sparse complains that __hyp_this_cpu_ptr() returns something
that is flagged noderef and not in the correct address space
(both being the result of the __percpu annotation).
Pretend that __hyp_this_cpu_ptr() knows what it is doing by
forcefully casting the pointer with __kernel __force.
For very long, we have kept this pointer back to the per-cpu
host state, despite having working per-cpu accessors at EL2
for some time now.
Recent investigations have shown that this pointer is easy
to abuse in preemptible context, which is a sure sign that
it would better be gone. Not to mention
16 matches
Mail list logo
