Hi Marc,
> -Original Message-
> From: Marc Zyngier
> Sent: Tuesday, January 7, 2020 5:29 PM
> To: Jianyong Wu
> Cc: net...@vger.kernel.org; yangbo...@nxp.com; john.stu...@linaro.org;
> t...@linutronix.de; pbonz...@redhat.com; sean.j.christopher...@intel.com;
> richardcoch...@gmail.com; M
Hi Marc,
> -Original Message-
> From: Marc Zyngier
> Sent: Tuesday, January 7, 2020 5:16 PM
> To: Jianyong Wu
> Cc: net...@vger.kernel.org; yangbo...@nxp.com; john.stu...@linaro.org;
> t...@linutronix.de; pbonz...@redhat.com; sean.j.christopher...@intel.com;
> richardcoch...@gmail.com; M
On 12/30/2019 01:57 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Implement primitives necessary for the 4th level folding, add walks of p4d
> level where appropriate, replace 5level-fixup.h with pgtable-nop4d.h and
> remove __ARCH_USE_5LEVEL_HACK.
>
> Since arm and arm64 share kvm memor
On 12/30/2019 01:57 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Hi,
Hello Mike,
>
> This is a part of clean up of the page table manipulation code that aims to
> remove asm-generic/5level-fixup.h and asm-generic/pgtable-nop4d-hack.h
>
> There is a single patch for both arm and arm64
Explicitly walk the host page tables to identify THP mappings instead
of relying solely on the metadata in struct page. This sets the stage
for using a common method of identifying huge mappings regardless of the
underlying implementation (HugeTLB vs THB vs DAX), and hopefully avoids
the pitfalls
This series is a mix of bug fixes, cleanup and new support in KVM's
handling of huge pages. The series initially stemmed from a syzkaller
bug report[1], which is fixed by patch 02, "mm: thp: KVM: Explicitly
check for THP when populating secondary MMU".
While investigating options for fixing the s
Open code an equivalent of kvm_vcpu_gfn_to_memslot() when querying the
host page size to avoid the "writable" check in __gfn_to_hva_many(),
which will always fail on read-only memslots due to gfn_to_hva()
assuming writes. Functionally, this allows x86 to create large mappings
for read-only memslot
Refactor transparent_hugepage_adjust() in preparation for walking the
host page tables to identify hugepage mappings, initially for THP pages,
and eventualy for HugeTLB and DAX-backed pages as well. The latter
cases support 1gb pages, i.e. the adjustment logic needs access to the
max allowed level
Add a helper, is_transparent_hugepage(), to explicitly check whether a
compound page is a THP and use it when populating KVM's secondary MMU.
The explicit check fixes a bug where a remapped compound page, e.g. for
an XDP Rx socket, is mapped into a KVM guest and is mistaken for a THP,
which results
Remove logic to retrieve the original gfn now that HugeTLB mappings are
are identified in FNAME(fetch), i.e. FNAME(page_fault) no longer adjusts
the level or gfn.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/paging_tmpl.h | 13 +++--
1 file changed, 3 insertions(+), 10 deletio
Remove KVM's HugeTLB specific logic and instead rely on walking the host
page tables (already done for THP) to identify HugeTLB mappings.
Eliminating the HugeTLB-only logic avoids taking mmap_sem and calling
find_vma() for all hugepage compatible page faults, and simplifies KVM's
page fault code by
Use kvm_vcpu_gfn_to_hva() when retrieving the host page size so that the
correct set of memslots is used when handling x86 page faults in SMM.
Fixes: 54bf36aac520 ("KVM: x86: use vcpu-specific functions to
read/write/translate GFNs")
Cc: sta...@vger.kernel.org
Signed-off-by: Sean Christopherson
Limit KVM's mapping level for HugeTLB based on its calculated max_level.
The max_level check prior to invoking host_mapping_level() only filters
out the case where KVM cannot create a 2mb mapping, it doesn't handle
the scenario where KVM can create a 2mb but not 1gb mapping, and the
host is using a
Add a helper, lookup_address_in_mm(), to traverse the page tables of a
given mm struct. KVM will use the helper to retrieve the host mapping
level, e.g. 4k vs. 2mb vs. 1gb, of a compound (or DAX-backed) page
without having to resort to implementation specific metadata. E.g. KVM
currently uses dif
Remove the late "lpage is disallowed" check from set_spte() now that the
initial check is performed after acquiring mmu_lock. Fold the guts of
the remaining helper, __mmu_gfn_lpage_is_disallowed(), into
kvm_mmu_hugepage_adjust() to eliminate the unnecessary slot !NULL check.
Signed-off-by: Sean C
Remove fast_page_fault()'s optimization to stop the shadow walk if the
iterator level drops below the intended map level. The intended map
level is only acccurate for HugeTLB mappings (THP mappings are detected
after fast_page_fault()), i.e. it's not required for correctness, and
a future patch wi
Walk the host page tables to identify hugepage mappings for ZONE_DEVICE
pfns, i.e. DAX pages. Explicitly query kvm_is_zone_device_pfn() when
deciding whether or not to bother walking the host page tables, as DAX
pages do not set up the head/tail infrastructure, i.e. will return false
for PageCompo
Zap any compound page, e.g. THP or HugeTLB pages, when zapping sptes
that can potentially be converted to huge sptes after disabling dirty
logging on the associated memslot. Note, this approach could result in
false positives, e.g. if a random compound page is mapped into the
guest, but mapping no
Fold max_mapping_level() into kvm_mmu_hugepage_adjust() now that HugeTLB
mappings are handled in kvm_mmu_hugepage_adjust(), i.e. there isn't a
need to pre-calculate the max mapping level. Co-locating all hugepage
checks eliminates a memslot lookup, at the cost of performing the
__mmu_gfn_lpage_is_
From: Raphael Gault
The EDK II UEFI firmware implementation requires some storage for the EFI
variables, which is typically some flash storage.
Since this is already supported on the EDK II side, we add a CFI flash
emulation to kvmtool.
This is backed by a file, specified via the --flash or -F co
On Wed, Jan 08, 2020 at 02:41:04PM +, Alexandru Elisei wrote:
> On 1/8/20 1:43 PM, Mark Rutland wrote:
> > When KVM injects an exception into a guest, it generates the CPSR value
> > from scratch, configuring CPSR.{M,A,I,T,E}, and setting all other
> > bits to zero.
> >
> > This isn't correct,
Hello,
On 1/8/20 1:43 PM, Mark Rutland wrote:
> When KVM injects an exception into a guest, it generates the CPSR value
> from scratch, configuring CPSR.{M,A,I,T,E}, and setting all other
> bits to zero.
>
> This isn't correct, as the architecture specifies that some CPSR bits
> are (conditionally
Hello,
On 1/8/20 1:43 PM, Mark Rutland wrote:
> When KVM injects an exception into a guest, it generates the PSTATE
> value from scratch, configuring PSTATE.{M[4:0],DAIF}, and setting all
> other bits to zero.
>
> This isn't correct, as the architecture specifies that some PSTATE bits
> are (condi
On Wed, Jan 08, 2020 at 01:43:21PM +, Mark Rutland wrote:
> Since v1 [2]:
> * Fix host_spsr_to_spsr32() bit preservation
> * Fix SPAN polarity; tested with a modified arm64 guest
> * Fix DIT preservation on 32-bit hosts
> * Add Alex's Reviewed-by to patch 3
>
> Thanks,
> Mark.
>
> [1]
> http
When KVM injects an exception into a guest, it generates the CPSR value
from scratch, configuring CPSR.{M,A,I,T,E}, and setting all other
bits to zero.
This isn't correct, as the architecture specifies that some CPSR bits
are (conditionally) cleared or set upon an exception, and others are
unchang
When KVM injects an exception into a guest, it generates the PSTATE
value from scratch, configuring PSTATE.{M[4:0],DAIF}, and setting all
other bits to zero.
This isn't correct, as the architecture specifies that some PSTATE bits
are (conditionally) cleared or set upon an exception, and others are
Confusingly, there are three SPSR layouts that a kernel may need to deal
with:
(1) An AArch64 SPSR_ELx view of an AArch64 pstate
(2) An AArch64 SPSR_ELx view of an AArch32 pstate
(3) An AArch32 SPSR_* view of an AArch32 pstate
When the KVM AArch32 support code deals with SPSR_{EL2,HYP}, it's eith
Hi,
While looking at the KVM code, I realised that our exception injection handling
isn't quite right, as it generates the target PSTATE/CPSR from scratch, and
doesn't handle all bits which need to be (conditionally) cleared or set upon
taking an exception.
The first two patches address this for
On Wed, Jan 08, 2020 at 12:36:11PM +, Marc Zyngier wrote:
> On 2020-01-08 11:58, Will Deacon wrote:
> > On Wed, Jan 08, 2020 at 11:17:16AM +, Marc Zyngier wrote:
> > > On 2020-01-07 15:13, Andrew Murray wrote:
> > > > Looking at the vcpu_load and related code, I don't see a way of saying
>
Hi,
On 1/8/20 11:12 AM, Mark Rutland wrote:
> Hi Alex,
>
> On Fri, Dec 27, 2019 at 01:01:57PM +, Alexandru Elisei wrote:
>> On 12/20/19 3:05 PM, Mark Rutland wrote:
>>> When KVM injects an exception into a guest, it generates the PSTATE
>>> value from scratch, configuring PSTATE.{M[4:0],DAIF},
On 2020-01-08 11:58, Will Deacon wrote:
On Wed, Jan 08, 2020 at 11:17:16AM +, Marc Zyngier wrote:
On 2020-01-07 15:13, Andrew Murray wrote:
> On Sat, Dec 21, 2019 at 02:13:25PM +, Marc Zyngier wrote:
> > On Fri, 20 Dec 2019 14:30:16 +
> > Andrew Murray wrote:
> >
> > [somehow manage
On Wed, Jan 08, 2020 at 11:17:16AM +, Marc Zyngier wrote:
> On 2020-01-07 15:13, Andrew Murray wrote:
> > On Sat, Dec 21, 2019 at 02:13:25PM +, Marc Zyngier wrote:
> > > On Fri, 20 Dec 2019 14:30:16 +
> > > Andrew Murray wrote:
> > >
> > > [somehow managed not to do a reply all, re-se
On Fri, Dec 27, 2019 at 03:42:34PM +, Alexandru Elisei wrote:
> Hi,
>
> On 12/20/19 3:05 PM, Mark Rutland wrote:
> > When KVM injects an exception into a guest, it generates the CPSR value
> > from scratch, configuring CPSR.{M,A,I,T,E}, and setting all other
> > bits to zero.
> >
> > This isn'
On 2020-01-07 15:13, Andrew Murray wrote:
On Sat, Dec 21, 2019 at 02:13:25PM +, Marc Zyngier wrote:
On Fri, 20 Dec 2019 14:30:16 +
Andrew Murray wrote:
[somehow managed not to do a reply all, re-sending]
> From: Sudeep Holla
>
> Now that we can save/restore the full SPE controls, we
On Sun, Dec 29, 2019 at 03:17:40PM +, Marc Zyngier wrote:
> On Fri, 27 Dec 2019 13:01:57 +,
> Alexandru Elisei wrote:
> > On 12/20/19 3:05 PM, Mark Rutland wrote:
> > > + // PSTATE.PAN is unchanged unless overridden by SCTLR_ELx.SPAN
> > > + // See ARM DDI 0487E.a, page D5-2578.
> > > + ne
Hi Alex,
On Fri, Dec 27, 2019 at 01:01:57PM +, Alexandru Elisei wrote:
> On 12/20/19 3:05 PM, Mark Rutland wrote:
> > When KVM injects an exception into a guest, it generates the PSTATE
> > value from scratch, configuring PSTATE.{M[4:0],DAIF}, and setting all
> > other bits to zero.
> >
> > Th
36 matches
Mail list logo
