On 2/4/20 4:43 PM, Dan Williams wrote:
Ah, got it, you only ended up at wanting namespace labels because
there was no other way to carve up device-dax. That's changing as part
of the efi_fake_mem= enabling and I have a patch set in the works to
allow discontiguous sub-divisions of a device-dax
Hi -
On 2/4/20 11:44 AM, Dan Williams wrote:
On Tue, Feb 4, 2020 at 7:30 AM Barret Rhoden wrote:
Hi -
On 1/10/20 2:03 PM, Joao Martins wrote:
User can define regions with 'memmap=size!offset' which in turn
creates PMEM legacy devices. But because it is a label-less
NVDIMM device we only
Hi -
On 1/10/20 2:03 PM, Joao Martins wrote:
User can define regions with 'memmap=size!offset' which in turn
creates PMEM legacy devices. But because it is a label-less
NVDIMM device we only have one namespace for the whole device.
Add support for multiple namespaces by adding ndctl control
Hi -
On 1/8/20 3:24 PM, Sean Christopherson wrote:
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
Hi -
On 1/7/20 2:05 PM, Sean Christopherson wrote:
On Mon, Dec 16, 2019 at 11:05:26AM -0500, Barret Rhoden wrote:
On 12/13/19 12:19 PM, Sean Christopherson wrote:
Teaching thp_adjust() how to handle 1GB wouldn't be a bad thing. It's
unlikely THP itself will support 1GB pages any time soon
On 12/13/19 12:47 PM, Sean Christopherson wrote:
+unsigned long dev_pagemap_mapping_shift(unsigned long address,
+ struct mm_struct *mm)
+{
+ pgd_t *pgd;
+ p4d_t *p4d;
+ pud_t *pud;
+ pmd_t *pmd;
+ pte_t *pte;
+
+ pgd =
On 12/13/19 12:19 PM, Sean Christopherson wrote:
Teaching thp_adjust() how to handle 1GB wouldn't be a bad thing. It's
unlikely THP itself will support 1GB pages any time soon, but having the
logic there wouldn't hurt anything.
Cool. This was my main concern - I didn't want to break THP.
On 12/12/19 8:07 PM, Liran Alon wrote:
I was a little hesitant to change the this to handle 1 GB pages with this
patchset at first. I didn't want to break the non-DAX case stuff by doing so.
Why would it affect non-DAX case?
Your patch should just make hugepage_adjust() to parse page-tables
On 12/12/19 2:48 PM, Dan Williams wrote:
On Thu, Dec 12, 2019 at 11:16 AM Barret Rhoden wrote:
On 12/12/19 12:37 PM, Dan Williams wrote:
Yeah, since device-dax is the only path to support longterm page
pinning for vfio device assignment, testing with device-dax + 1GB
pages would be a useful
Hi -
On 12/12/19 1:49 PM, Liran Alon wrote:
On 12 Dec 2019, at 20:47, Liran Alon wrote:
On 12 Dec 2019, at 20:22, Barret Rhoden wrote:
This change allows KVM to map DAX-backed files made of huge pages with
huge mappings in the EPT/TDP.
This change isn’t only relevant for TDP
On 12/12/19 12:37 PM, Dan Williams wrote:
Yeah, since device-dax is the only path to support longterm page
pinning for vfio device assignment, testing with device-dax + 1GB
pages would be a useful sanity check.
What are the issues with fs-dax and page pinning? Is that limitation
something
b...@google.com/
Barret Rhoden (2):
mm: make dev_pagemap_mapping_shift() externally visible
kvm: Use huge pages for DAX-backed files
arch/x86/kvm/mmu/mmu.c | 31 +++
include/linux/mm.h | 3 +++
mm/memory-failure.c| 38 +++---
).
Signed-off-by: Barret Rhoden
Reviewed-by: David Hildenbrand
Acked-by: Dan Williams
---
include/linux/mm.h | 3 +++
mm/memory-failure.c | 38 +++---
mm/util.c | 34 ++
3 files changed, 40 insertions(+), 35 deletions(-)
diff
PageTransCompound.
For DAX, we can check the page table itself.
Note that KVM already faulted in the page (or huge page) in the host's
page table, and we hold the KVM mmu spinlock. We grabbed that lock in
kvm_mmu_notifier_invalidate_range_end, before checking the mmu seq.
Signed-off-by: Barret Rhoden
On 12/12/19 7:33 AM, Liran Alon wrote:
+ /*
+* Our caller grabbed the KVM mmu_lock with a successful
+* mmu_notifier_retry, so we're safe to walk the page table.
+*/
+ switch (dev_pagemap_mapping_shift(hva, current->mm)) {
Doesn’t dev_pagemap_mapping_shift()
On 12/12/19 7:22 AM, David Hildenbrand wrote:
+ /*
+* Our caller grabbed the KVM mmu_lock with a successful
+* mmu_notifier_retry, so we're safe to walk the page table.
+*/
+ switch (dev_pagemap_mapping_shift(hva, current->mm)) {
+ case PMD_SHIFT:
+
KVM has a use case for determining the size of a dax mapping. The KVM
code has easy access to the address and the mm; hence the change in
parameters.
Signed-off-by: Barret Rhoden
Reviewed-by: David Hildenbrand
Acked-by: Dan Williams
---
include/linux/mm.h | 3 +++
mm/memory-failure.c | 38
ad:
https://lore.kernel.org/lkml/20181029210716.212159-1-b...@google.com/
Barret Rhoden (2):
mm: make dev_pagemap_mapping_shift() externally visible
kvm: Use huge pages for DAX-backed files
arch/x86/kvm/mmu/mmu.c | 36
include/linux/mm.h | 3 +++
mm/memory-failure.
PageTransCompound.
For DAX, we can check the page table itself.
Note that KVM already faulted in the page (or huge page) in the host's
page table, and we hold the KVM mmu spinlock. We grabbed that lock in
kvm_mmu_notifier_invalidate_range_end, before checking the mmu seq.
Signed-off-by: Barret Rhoden
-yi.z.zh...@intel.com (Bad email address / failure)
Sorry about that.
On 4/4/19 4:23 PM, Barret Rhoden wrote:
This patch series depends on DAX pages not being PageReserved. Once
that is in place, these changes will let KVM use huge pages with
DAX-backed files.
From previous discussions[1
kvm_is_reserved_pfn() already checks PageReserved().
Signed-off-by: Barret Rhoden
Reviewed-by: David Hildenbrand
---
virt/kvm/kvm_main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 55fe8e20d8fd..c44985375e7f 100644
PageTransCompound.
For DAX, we can check the page table itself.
Note that KVM already faulted in the page (or huge page) in the host's
page table, and we hold the KVM mmu spinlock. We grabbed that lock in
kvm_mmu_notifier_invalidate_range_end, before checking the mmu seq.
Signed-off-by: Barret Rhoden
KVM has a use case for determining the size of a dax mapping. The KVM
code has easy access to the address and the mm; hence the change in
parameters.
Signed-off-by: Barret Rhoden
Reviewed-by: David Hildenbrand
Acked-by: Dan Williams
---
include/linux/mm.h | 3 +++
mm/memory-failure.c | 38
touchups
- Added patch to remove redundant PageReserved() check
- Rebased onto linux-next
RFC/discussion thread:
https://lore.kernel.org/lkml/20181029210716.212159-1-b...@google.com/
[1]
https://lore.kernel.org/lkml/ee8cc068-903c-d87e-f418-ade467862...@redhat.com/
Barret Rhoden (3):
Hi -
On 2018-12-04 at 14:51 Alexander Duyck
wrote:
[snip]
> > I think the confusion arises from the fact that there are a few MMIO
> > resources with a struct page and all the rest MMIO resources without.
> > The problem comes from the coarse definition of pfn_valid(), it may
> > return 'true'
ost - just Ack/Review tags. It's harmless
with the existing PageReserved behavior.
Thanks,
Barret
> On Wed, Nov 14, 2018 at 1:53 PM Barret Rhoden wrote:
> >
> > This patch series depends on dax pages not being PageReserved. Once
> > that is in place, these changes wil
KVM has a use case for determining the size of a dax mapping. The KVM
code has easy access to the address and the mm; hence the change in
parameters.
Signed-off-by: Barret Rhoden
Reviewed-by: David Hildenbrand
---
include/linux/mm.h | 3 +++
mm/memory-failure.c | 38
PageTransCompound.
For DAX, we can check the page table itself.
Note that KVM already faulted in the page (or huge page) in the host's
page table, and we hold the KVM mmu spinlock. We grabbed that lock in
kvm_mmu_notifier_invalidate_range_end, before checking the mmu seq.
Signed-off-by: Barret Rhoden
/discussion thread:
https://lore.kernel.org/lkml/20181029210716.212159-1-b...@google.com/
v1 -> v2:
https://lore.kernel.org/lkml/20181109203921.178363-1-b...@google.com/
- Updated Acks/Reviewed-by
- Minor touchups
- Added patch to remove redundant PageReserved() check
- Rebased onto linux-next
Bar
kvm_is_reserved_pfn() already checks PageReserved().
Signed-off-by: Barret Rhoden
---
virt/kvm/kvm_main.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2679e476b6c3..e0ea6d7dac14 100644
--- a/virt/kvm/kvm_main.c
+++ b
On 2018-11-12 at 20:31 Paolo Bonzini wrote:
> Looks good. What's the plan for removing PageReserved from DAX pages?
I hear that's going on in this thread:
https://lore.kernel.org/lkml/154145268025.30046.11742652345962594283.st...@ahduyck-desk1.jf.intel.com/
Though it looks like it's speeding
On 2018-11-13 at 05:02 Pankaj Gupta wrote:
> As this patch is dependent on PageReserved patch(which is in progress), just
> wondering if we are able to test the code path for hugepage with DAX.
For testing, I used the following patch. It's not 100%, since it
intercepts at
On 2018-11-13 at 10:36 David Hildenbrand wrote:
> > Note that KVM already faulted in the page (or huge page) in the host's
> > page table, and we hold the KVM mmu spinlock (grabbed before checking
> > the mmu seq).
>
> I wonder if the KVM mmu spinlock is enough for walking (not KVM
>
/discussion thread:
https://lore.kernel.org/lkml/20181029210716.212159-1-b...@google.com/
Barret Rhoden (2):
mm: make dev_pagemap_mapping_shift() externally visible
kvm: Use huge pages for DAX-backed files
arch/x86/kvm/mmu.c | 34 --
include/linux/mm.h | 3
PageTransCompound.
For DAX, we can check the page table itself.
Note that KVM already faulted in the page (or huge page) in the host's
page table, and we hold the KVM mmu spinlock (grabbed before checking
the mmu seq).
Signed-off-by: Barret Rhoden
---
arch/x86/kvm/mmu.c | 34
On 2018-11-06 at 22:16 Paolo Bonzini wrote:
> Yes, iter.gfn is the gfn inside the loop and iter.level is the level
> (1=PTE, 2=PDE, ...). iter.level of course is unusable here, similar to
> *levelp in transparent_hugepage_adjust, but you can use iter.gfn and
> gfn_to_hva.
Great, thanks!
On 2018-11-06 at 11:19 Paolo Bonzini wrote:
> > void kvm_set_pfn_dirty(kvm_pfn_t pfn)
> > {
> > if (!kvm_is_reserved_pfn(pfn)) {
> > struct page *page = pfn_to_page(pfn);
> >
> > if (!PageReserved(page))
> > SetPageDirty(page);
> >
On 2018-10-31 at 09:49 Paolo Bonzini wrote:
> > On 2018-10-29 at 20:10 Dan Williams wrote:
> >> The property of DAX pages that requires special coordination is the
> >> fact that the device hosting the pages can be disabled at will. The
> >> get_dev_pagemap() api is the interface to pin a
On 2018-10-29 at 20:10 Dan Williams wrote:
> > > > static void transparent_hugepage_adjust(struct kvm_vcpu *vcpu,
> > > > gfn_t *gfnp, kvm_pfn_t *pfnp,
> > > > int *levelp)
> > > > @@ -3168,7 +3237,7 @@ static void
On 2018-10-29 at 15:25 Dan Williams wrote:
> > + /*
> > +* Our caller grabbed the KVM mmu_lock with a successful
> > +* mmu_notifier_retry, so we're safe to walk the page table.
> > +*/
> > + map_sz = pgd_mapping_size(current->mm, hva);
> > + switch
there?
Alternatively, is there a better way to track at the struct page level
whether or not a page is huge-mapped? Maybe the DAX huge pages mark
themselves as TransCompound or something similar, and we don't need to
special case DAX/ZONE_DEVICE pages.
Signed-off-by: Barret Rhoden
---
arch/x86
On 2018-09-21 at 21:29 David Hildenbrand wrote:
> On 21/09/2018 20:17, Dan Williams wrote:
> > On Fri, Sep 21, 2018 at 7:24 AM David Hildenbrand wrote:
> > [..]
> >>> Remove the PageReserved flag sounds more reasonable.
> >>> And Could we still have a flag to identify it is a device private
Hi Dan -
On 2018-07-04 at 14:41 Dan Williams wrote:
[snip]
> diff --git a/fs/dax.c b/fs/dax.c
> index 4de11ed463ce..57ec272038da 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
[snip]
> +bool dax_lock_mapping_entry(struct page *page)
> +{
> + pgoff_t index;
> + struct inode *inode;
> + bool
43 matches
Mail list logo
