Hi Keqian,
On 4/16/21 12:03 AM, Keqian Zhu wrote:
The MMIO region of a device maybe huge (GB level), try to use
block mapping in stage2 to speedup both map and unmap.
Compared to normal memory mapping, we should consider two more
points when try block mapping for MMIO region:
1. For normal
On Tue, Apr 20, 2021 at 06:00:55PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The arm64's version of pfn_valid() differs from the generic because of two
> > reasons:
> >
> > * Parts of the memory map are freed during boot. This
On Tue, Apr 20, 2021 at 05:57:57PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The intended semantics of pfn_valid() is to verify whether there is a
> > struct page for the pfn in question and nothing else.
> >
> > Yet, on arm64 it
Hi Keqian,
On 4/16/21 12:03 AM, Keqian Zhu wrote:
The MMIO regions may be unmapped for many reasons and can be remapped
by stage2 fault path. Map MMIO regions at creation time becomes a
minor optimization and makes these two mapping path hard to sync.
Remove the mapping code while keep the
Hi Keqian and Santosh,
On 4/21/21 12:59 PM, Keqian Zhu wrote:
On 2020/10/22 0:16, Santosh Shukla wrote:
The Commit:6d674e28 introduces a notion to detect and handle the
device mapping. The commit checks for the VM_PFNMAP flag is set
in vma->flags and if set then marks force_pte to true such
Hi Santosh,
On 2020/10/22 0:16, Santosh Shukla wrote:
> The Commit:6d674e28 introduces a notion to detect and handle the
> device mapping. The commit checks for the VM_PFNMAP flag is set
> in vma->flags and if set then marks force_pte to true such that
> if force_pte is true then ignore the THP
Hi Alex,
On Tue, Apr 20, 2021 at 05:13:37PM +0100, Alexandru Elisei wrote:
> This is an RFC because it's not exactly clear to me that this is the best
> approach. I'm also open to using a different name for the new option, maybe
> something like --platform if it makes more sense.
I like
On Sat, 17 Apr 2021 19:38:04 +0800, Zenghui Yu wrote:
> Per include/linux/arm-smccc.h, the Function ID of PTP_KVM service is
> defined as ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID. Fix the typo in
> documentation to keep the git grep consistent.
Applied to kvm-arm64/ptp, thanks!
[1/1] KVM: arm64: Fix
This is an RFC because it's not exactly clear to me that this is the best
approach. I'm also open to using a different name for the new option, maybe
something like --platform if it makes more sense.
I see two use cases for the patch:
1. Using different files when compiling kvm-unit-tests to run
The --vmm configure option was added to distinguish between the two virtual
machine managers that kvm-unit-tests supports, qemu or kvmtool. There are
plans to make kvm-unit-tests work as an EFI app, which will require changes
to the way tests are compiled. Instead of adding a new configure option
On 20.04.21 11:09, Mike Rapoport wrote:
From: Mike Rapoport
The arm64's version of pfn_valid() differs from the generic because of two
reasons:
* Parts of the memory map are freed during boot. This makes it necessary to
verify that there is actual physical memory that corresponds to a pfn
On 20.04.21 11:09, Mike Rapoport wrote:
From: Mike Rapoport
The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.
Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require
On Tue, Apr 20, 2021 at 05:18:55PM +0200, David Hildenbrand wrote:
> On 20.04.21 17:03, Mike Rapoport wrote:
> > On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> > > On 20.04.21 11:09, Mike Rapoport wrote:
> > > > From: Mike Rapoport
> > > >
> > > > The struct pages
On 20.04.21 17:03, Mike Rapoport wrote:
On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
On 20.04.21 11:09, Mike Rapoport wrote:
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function
On Tue, Apr 20, 2021 at 03:56:28PM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > The struct pages representing a reserved memory region are initialized
> > using reserve_bootmem_range() function. This function is called for each
> >
On 20.04.21 11:09, Mike Rapoport wrote:
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.
On Tue, 20 Apr 2021 14:08:24 +0100,
Yoan Picchi wrote:
>
> This patch adds regular_page_mapped and huge_page_mapped.
> regular_page_mapped is increased when a page of the smallest granularity
> is mapped. This is usually a 4k, 16k or 64k page.
> huge_page_mapped is increased when a huge page of
This patch adds regular_page_mapped and huge_page_mapped.
regular_page_mapped is increased when a page of the smallest granularity
is mapped. This is usually a 4k, 16k or 64k page.
huge_page_mapped is increased when a huge page of any size other than the
smallest granularity is mapped.
Those
Hi all,
Considering the feedback on my first version
https://lore.kernel.org/linux-arm-kernel/20210319161711.24972-1-yoan.pic...@arm.com/
I started from scratch and focussed only on stage 2 page fault.
For the context, as mentioned in the KVM forum talk from 2019
This counter is meant to detect when the guest vm exits due to an
interrupt. Those interrupts might be unrelated to the guest VM (say, some
network packet arrived, and such) but they still trigger an exit which is
recorded by the "exit" counter. The main purpose of this counter is to
give some
This counter is meant to detect stage 2 page fault exits. This is meant to
measure how much those page fault influence the performance (by comparing
this number of exits to some other exit causes).
For now this counter is generic, but some more granularity is planned in
the next commits so that
On Tue, 20 Apr 2021 14:08:23 +0100,
Yoan Picchi wrote:
>
> This counter is meant to detect stage 2 page fault exits. This is meant to
> measure how much those page fault influence the performance (by comparing
> this number of exits to some other exit causes).
> For now this counter is generic,
On Tue, 20 Apr 2021 14:08:25 +0100,
Yoan Picchi wrote:
>
> This counter is meant to detect when the guest vm exits due to an
> interrupt. Those interrupts might be unrelated to the guest VM (say, some
> network packet arrived, and such) but they still trigger an exit which is
> recorded by the
On 20.04.21 14:57, Mike Rapoport wrote:
On Tue, Apr 20, 2021 at 11:22:53AM +0200, David Hildenbrand wrote:
On 20.04.21 11:09, Mike Rapoport wrote:
From: Mike Rapoport
Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory
On Tue, Apr 20, 2021 at 11:22:53AM +0200, David Hildenbrand wrote:
> On 20.04.21 11:09, Mike Rapoport wrote:
> > From: Mike Rapoport
> >
> > Add comment describing the semantics of pfn_valid() that clarifies that
> > pfn_valid() only checks for availability of a memory map entry (i.e. struct
> >
On 20.04.21 11:09, Mike Rapoport wrote:
From: Mike Rapoport
Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.
The most
From: Mike Rapoport
The arm64's version of pfn_valid() differs from the generic because of two
reasons:
* Parts of the memory map are freed during boot. This makes it necessary to
verify that there is actual physical memory that corresponds to a pfn
which is done by querying memblock.
*
From: Mike Rapoport
The intended semantics of pfn_valid() is to verify whether there is a
struct page for the pfn in question and nothing else.
Yet, on arm64 it is used to distinguish memory areas that are mapped in the
linear map vs those that require ioremap() to access them.
Introduce a
From: Mike Rapoport
The struct pages representing a reserved memory region are initialized
using reserve_bootmem_range() function. This function is called for each
reserved region just before the memory is freed from memblock to the buddy
page allocator.
The struct pages for MEMBLOCK_NOMAP
From: Mike Rapoport
Add comment describing the semantics of pfn_valid() that clarifies that
pfn_valid() only checks for availability of a memory map entry (i.e. struct
page) for a PFN rather than availability of usable memory backing that PFN.
The most "generic" version of pfn_valid() used by
From: Mike Rapoport
Hi,
These patches aim to remove CONFIG_HOLES_IN_ZONE and essentially hardwire
pfn_valid_within() to 1.
The idea is to mark NOMAP pages as reserved in the memory map and restore
the intended semantics of pfn_valid() to designate availability of struct
page for a pfn.
With
31 matches
Mail list logo
