On 3/24/21 7:00 PM, Joao Martins wrote:
> On 3/24/21 5:45 PM, Dan Williams wrote:
>> On Thu, Mar 18, 2021 at 3:02 AM Joao Martins
>> wrote:
>>> On 3/18/21 4:08 AM, Dan Williams wrote:
>>>> Now that device-dax and filesystem-dax are guaranteed to unmap all user
On 3/24/21 5:45 PM, Dan Williams wrote:
> On Thu, Mar 18, 2021 at 3:02 AM Joao Martins
> wrote:
>> On 3/18/21 4:08 AM, Dan Williams wrote:
>>> Now that device-dax and filesystem-dax are guaranteed to unmap all user
>>> mappings of devmap / DAX pages before
On 3/18/21 4:08 AM, Dan Williams wrote:
> Now that device-dax and filesystem-dax are guaranteed to unmap all user
> mappings of devmap / DAX pages before tearing down the 'struct page'
> array, get_user_pages_fast() can rely on its traditional synchronization
> method "validate_pte(); get_page(); r
On 2/18/21 3:33 PM, Joao Martins wrote:
> On 2/18/21 7:24 AM, Christoph Hellwig wrote:
>> On Fri, Feb 12, 2021 at 01:08:39PM +0000, Joao Martins wrote:
>>> Hey,
>>>
>>> This series improves page unpinning, with an eye on improving MR
>>> deregistra
On 2/18/21 7:24 AM, Christoph Hellwig wrote:
> On Fri, Feb 12, 2021 at 01:08:39PM +0000, Joao Martins wrote:
>> Hey,
>>
>> This series improves page unpinning, with an eye on improving MR
>> deregistration for big swaths of memory (which is bound by the page
>>
) where each sg represents a
contiguous set of pages, we're able to more efficiently unpin
pages without having to supply an array of pages much of what
happens today with unpin_user_pages().
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
Reviewed-by: Jason Gunthorpe
Reviewed-by:
rounds in 60.001 sec: 1845.225 usec / round
Signed-off-by: Joao Martins
Acked-by: Jason Gunthorpe
---
drivers/infiniband/core/umem.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index
age range without having to walk page arrays (Jason)
* Use unsigned for number of tails (Jason)
Joao Martins (4):
mm/gup: add compound page list iterator
mm/gup: decrement head page once for group of subpages
mm/gup: add a range variant of unpin_user_pages_dirty_lock()
RDMA/umem:
consecutive tail pages.
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
Reviewed-by: John Hubbard
Reviewed-by: Jason Gunthorpe
---
mm/gup.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index e40579624f10..1a709eae2bfd 100644
--- a/mm
-> ~23.2k us
- 16G with 1G huge page size
gup_test -f /mnt/huge/file -m 16384 -r 10 [-L|-a] -S -n 512 -w
PIN_LONGTERM_BENCHMARK: (put values): ~87.6k us -> ~27.5k us
Signed-off-by: Joao Martins
Reviewed-by: John Hubbard
Reviewed-by: Jason Gunthorpe
---
mm/gup.c | 29 +++--
On 2/10/21 11:19 PM, John Hubbard wrote:
> On 2/5/21 12:41 PM, Joao Martins wrote:
>> Add a unpin_user_page_range_dirty_lock() API which takes a starting page
>> and how many consecutive pages we want to unpin and optionally dirty.
>>
>> To that e
On 2/10/21 11:20 PM, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 08:41:24PM +0000, Joao Martins wrote:
>> Add an helper that iterates over head pages in a list of pages. It
>> essentially counts the tails until the next page to process has a
>> different head that the c
On 2/10/21 11:17 PM, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 08:41:27PM +0000, Joao Martins wrote:
>> Use the newly added unpin_user_page_range_dirty_lock()
>> for more quickly unpinning a consecutive range of pages
>> represented as compound pages. This will also c
On 2/10/21 11:15 PM, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 08:41:26PM +0000, Joao Martins wrote:
>> Add a unpin_user_page_range_dirty_lock() API which takes a starting page
>> and how many consecutive pages we want to unpin and optionally dirty.
>>
>>
On 2/10/21 9:02 PM, Jason Gunthorpe wrote:
> On Fri, Feb 05, 2021 at 08:41:25PM +0000, Joao Martins wrote:
>> Rather than decrementing the head page refcount one by one, we
>> walk the page array and checking which belong to the same
>> compound_head. Later on we decrement
On 1/26/21 2:13 AM, Shiyang Ruan wrote:
> The return value of range_parse() indicates the size when it is
> positive. The error code should be negative.
>
> Signed-off-by: Shiyang Ruan
Reviewed-by: Joao Martins
Although, FWIW, there was another patch exactly like this a coupl
On 2/9/21 8:19 AM, Christoph Hellwig wrote:
> On Mon, Feb 08, 2021 at 07:26:25PM -0400, Jason Gunthorpe wrote:
page_mkclean() has some technique to make the notifier have the right
size without becoming entangled in the PTL locks..
>>>
>>> Right. I guess it's because dax doesn't have "st
6/kvm/xen.c: In function ‘kvm_xen_write_hypercall_page’:
> arch/x86/kvm/xen.c:300:22: error: cast to pointer from integer of
> different size [-Werror=int-to-pointer-cast]
> 300 | page = memdup_user((u8 __user *)blob_addr, PAGE_SIZE);
>
> Cc: Joao
On 2/4/21 3:50 AM, Muchun Song wrote:
> Hi all,
>
[...]
> When a HugeTLB is freed to the buddy system, we should allocate 6 pages for
> vmemmap pages and restore the previous mapping relationship.
>
> Apart from 2MB HugeTLB page, we also have 1GB HugeTLB page. It is similar
> to the 2MB HugeTLB
consecutive tail pages.
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
Reviewed-by: John Hubbard
---
mm/gup.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index d68bcb482b11..8defe4f670d5 100644
--- a/mm/gup.c
+++ b/mm/gup.c
-> ~23.2k us
- 16G with 1G huge page size
gup_test -f /mnt/huge/file -m 16384 -r 10 [-L|-a] -S -n 512 -w
PIN_LONGTERM_BENCHMARK: (put values): ~87.6k us -> ~27.5k us
Signed-off-by: Joao Martins
Reviewed-by: John Hubbard
---
mm/gup.c | 29 +++--
1 file changed, 11 i
rounds in 60.001 sec: 1845.225 usec / round
Signed-off-by: Joao Martins
---
drivers/infiniband/core/umem.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 2dde99a9ba07..9b607013e2a2 100644
) where each sg represents a
contiguous set of pages, we're able to more efficiently unpin
pages without having to supply an array of pages much of what
happens today with unpin_user_pages().
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
---
include/linux/mm.h | 2 ++
mm/
in_user_page_range_dirty_lock() to unpin based
on a consecutive page range without having to walk page arrays (Jason)
* Use unsigned for number of tails (Jason)
Joao Martins (4):
mm/gup: add compound page list iterator
mm/gup: decrement head page once for group of subpage
On 2/4/21 8:00 PM, Jason Gunthorpe wrote:
> On Wed, Feb 03, 2021 at 04:15:53PM -0800, John Hubbard wrote:
>>> diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
>>> index 2dde99a9ba07..ea4ebb3261d9 100644
>>> +++ b/drivers/infiniband/core/umem.c
>>> @@ -47,17 +47,17 @@
On 2/4/21 8:18 PM, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 79033bebf6fa ("KVM: x86/xen: Fix coexistence of Xen and Hyper-V hypercalls")
>
> is missing a Signed-off-by from its author.
>
Except that David is the author of this particular patch, not me.
Joao
On 2/5/21 4:49 AM, John Hubbard wrote:
> On 2/4/21 12:24 PM, Joao Martins wrote:
>> Add a unpin_user_page_range_dirty_lock() API which takes a starting page
>> and how many consecutive pages we want to unpin and optionally dirty.
>>
>> Given that we won't be iterat
On 2/5/21 4:11 AM, John Hubbard wrote:
> On 2/4/21 12:24 PM, Joao Martins wrote:
>> Add an helper that iterates over head pages in a list of pages. It
>> essentially counts the tails until the next page to process has a
>> different head that the current. This i
rounds in 60.001 sec: 1845.225 usec / round
Signed-off-by: Joao Martins
---
drivers/infiniband/core/umem.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 2dde99a9ba07..9b607013e2a2 100644
y of pages much of what
happens today with unpin_user_pages().
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
---
include/linux/mm.h | 2 ++
mm/gup.c | 64 ++
2 files changed, 66 insertions(+)
diff --git a/include/linux/mm.h b/inc
-> ~23.2k us
- 16G with 1G huge page size
gup_test -f /mnt/huge/file -m 16384 -r 10 [-L|-a] -S -n 512 -w
PIN_LONGTERM_BENCHMARK: (put values): ~87.6k us -> ~27.5k us
Signed-off-by: Joao Martins
Reviewed-by: John Hubbard
---
mm/gup.c | 29 +++--
1 file changed, 11 i
page_range_dirty_lock() to unpin based
on a consecutive page range without having to walk page arrays (Jason)
* Use unsigned for number of tails (Jason)
Joao Martins (4):
mm/gup: add compound page list iterator
mm/gup: decrement head page once for group of subpages
mm/g
consecutive tail pages.
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
---
mm/gup.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index d68bcb482b11..d1549c61c2f6 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -215,6 +215,35 @@ void
On 2/4/21 11:35 AM, Joao Martins wrote:
> On 2/3/21 11:37 PM, John Hubbard wrote:
>> On 2/3/21 2:00 PM, Joao Martins wrote:
>>> -static inline unsigned int count_ntails(struct page **pages, unsigned long
>>> npages)
>>> +static inline unsigned
On 2/4/21 11:27 AM, Joao Martins wrote:
> On 2/3/21 11:00 PM, John Hubbard wrote:
>> On 2/3/21 2:00 PM, Joao Martins wrote:
>>> Add an helper that iterates over head pages in a list of pages. It
>>> essentially counts the tails until the next page to process has a
On 2/4/21 12:15 AM, John Hubbard wrote:
> On 2/3/21 2:00 PM, Joao Martins wrote:
>> Use the newly added unpin_user_page_range_dirty_lock()
>> for more quickly unpinning a consecutive range of pages
>> represented as compound pages. This will also calculate
>> number
On 2/4/21 12:11 AM, John Hubbard wrote:
> On 2/3/21 2:00 PM, Joao Martins wrote:
> ...
>> +void unpin_user_page_range_dirty_lock(struct page *page, unsigned long
>> npages,
>> + bool make_dirty)
>> +{
>> +unsigned l
On 2/3/21 11:37 PM, John Hubbard wrote:
> On 2/3/21 2:00 PM, Joao Martins wrote:
>> Add a unpin_user_page_range() API which takes a starting page
>> and how many consecutive pages we want to dirty.
>>
>> Given that we won't be iterating on a list of changes, chan
On 2/3/21 11:00 PM, John Hubbard wrote:
> On 2/3/21 2:00 PM, Joao Martins wrote:
>> Add an helper that iterates over head pages in a list of pages. It
>> essentially counts the tails until the next page to process has a
>> different head that the current. This i
On 2/3/21 11:28 PM, John Hubbard wrote:
> On 2/3/21 2:00 PM, Joao Martins wrote:
>> Rather than decrementing the head page refcount one by one, we
>> walk the page array and checking which belong to the same
>> compound_head. Later on we decrement the calculated amount
folio iterators (Jason)
Introduce an alternative unpin_user_page_range_dirty_lock() to unpin based
on a consecutive page range without having to walk page arrays (Jason)
* Use unsigned for number of tails (Jason)
Joao Martins (4):
mm/gup: add compound page list iterator
mm/gup: decrement head page
today with unpin_user_pages().
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
---
include/linux/mm.h | 2 ++
mm/gup.c | 48 ++
2 files changed, 42 insertions(+), 8 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/
-> ~23.2k us
- 16G with 1G huge page size
gup_test -f /mnt/huge/file -m 16384 -r 10 [-L|-a] -S -n 512 -w
PIN_LONGTERM_BENCHMARK: (put values): ~87.6k us -> ~27.5k us
Signed-off-by: Joao Martins
---
mm/gup.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(
consecutive tail pages.
Suggested-by: Jason Gunthorpe
Signed-off-by: Joao Martins
---
mm/gup.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index d68bcb482b11..4f88dcef39f2 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -215,6 +215,35 @@ void
rounds in 60.001 sec: 1897.267 usec / round
Signed-off-by: Joao Martins
---
drivers/infiniband/core/umem.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index 2dde99a9ba07..ea4ebb3261d9 100644
On 2/3/21 3:32 PM, Joao Martins wrote:
> On 2/3/21 2:51 PM, Pavel Tatashin wrote:
>> On Wed, Feb 3, 2021 at 8:23 AM Joao Martins
>> wrote:
>>> On 1/25/21 7:47 PM, Pavel Tatashin wrote:
>>> for compound pages but when !is_transparent_hugepage(head)
On 2/3/21 2:53 PM, Jason Gunthorpe wrote:
> On Wed, Feb 03, 2021 at 01:22:18PM +0000, Joao Martins wrote:
>
>> With this, longterm gup will 'regress' for hugetlbfs e.g. from ~6k -> ~32k
>> usecs when
>> pinning a 16G hugetlb file.
>
> Yes, but correct
On 2/3/21 2:51 PM, Pavel Tatashin wrote:
> On Wed, Feb 3, 2021 at 8:23 AM Joao Martins wrote:
>>
>> On 1/25/21 7:47 PM, Pavel Tatashin wrote:
>>> When pages are isolated in check_and_migrate_movable_pages() we skip
>>> compound number of pages at a time. Howev
On 1/25/21 7:47 PM, Pavel Tatashin wrote:
> When pages are isolated in check_and_migrate_movable_pages() we skip
> compound number of pages at a time. However, as Jason noted, it is
> not necessary correct that pages[i] corresponds to the pages that
> we skipped. This is because it is possible that
On 1/29/21 4:32 PM, Pavel Tatashin wrote:
> On Fri, Jan 29, 2021 at 9:51 AM Joao Martins
> wrote:
>>
>> Hey Pavel,
>>
>> On 1/29/21 1:50 PM, Pavel Tatashin wrote:
>>>> Since we last talked about this the enabling for EFI "Special Purpose&quo
() on the second patch;
[0]
https://lore.kernel.org/linux-mm/20201208172901.17384-11-joao.m.mart...@oracle.com/
Joao Martins (2):
mm/hugetlb: grab head page refcount once for group of subpages
mm/hugetlb: refactor subpage recording
include/linux/mm.h | 3 +++
mm/gup.c | 5 ++-
we reduce the number of atomics necessary to pin
said huge page, which improves non-fast gup() considerably:
- 16G with 1G huge page size
gup_test -f /mnt/huge/file -m 16384 -r 10 -L -S -n 512 -w
PIN_LONGTERM_BENCHMARK: ~87.6k us -> ~12.8k us
Reviewed-by: Mike Kravetz
Signed-off-by: J
GTERM_BENCHMARK: ~12.8k us -> ~5.8k us
PIN_FAST_BENCHMARK: ~3.7k us
Signed-off-by: Joao Martins
---
mm/hugetlb.c | 49 -
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index becef936ec21..f3baabbda4
On 1/26/21 6:08 PM, Mike Kravetz wrote:
> On 1/25/21 12:57 PM, Joao Martins wrote:
>> For a given hugepage backing a VA, there's a rather ineficient
>> loop which is solely responsible for storing subpages in the passed
>> pages/vmas array. For each subpage we check wheth
On 1/26/21 9:21 PM, Mike Kravetz wrote:
> On 1/26/21 11:21 AM, Joao Martins wrote:
>> On 1/26/21 6:08 PM, Mike Kravetz wrote:
>>> On 1/25/21 12:57 PM, Joao Martins wrote:
>>>>
>>>> +static void record_subpages_vmas(struct pa
On 1/26/21 7:21 PM, Joao Martins wrote:
> On 1/26/21 6:08 PM, Mike Kravetz wrote:
>> On 1/25/21 12:57 PM, Joao Martins wrote:
>>> For a given hugepage backing a VA, there's a rather ineficient
>>> loop which is solely responsible for storing subpages in the passe
us -> ~11k us
Signed-off-by: Joao Martins
---
include/linux/mm.h | 3 +++
mm/gup.c | 5 ++---
mm/hugetlb.c | 43 ---
3 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index a5d618d08
nsiderably, bringing us close to
{pin,get}_user_pages_fast:
- 16G with 1G huge page size
gup_test -f /mnt/huge/file -m 16384 -r 10 -L -S -n 512 -w
PIN_LONGTERM_BENCHMARK: ~11k us -> ~4400 us
PIN_FAST_BENCHMARK: ~3700 us
Signed-off-by: Joao Martins
---
mm/h
subpages/vmas. Both together bring the cost of slow
variant of gup() cost from ~86k usecs to ~4.4k usecs.
libhugetlbfs tests seem to pass as well gup_test benchmarks
with hugetlbfs vmas.
[0]
https://lore.kernel.org/linux-mm/20201208172901.17384-11-joao.m.mart...@oracle.com/
Joao Martins (2):
mm
On 12/12/20 5:29 PM, Matthew Wilcox wrote:
> And most urgently, when should we have the GUP meeting? On the call,
> I suggested Friday the 8th of January, but I'm happy to set something
> up for next week if we'd like to talk more urgently. Please propose a
> date & time. I know we have people i
On 1/1/21 2:33 PM, David Woodhouse wrote:
> On Wed, 2020-12-02 at 18:34 +0000, Joao Martins wrote:
>>> But if the kernel is going to short-circuit the IPIs and VIRQs, then
>>> it's already going to have to handle the evtchn_pending/evtchn_mask
>>> bitmaps
On 12/9/20 3:41 PM, David Woodhouse wrote:
> On 9 December 2020 13:26:55 GMT, Joao Martins
> wrote:
>> On 12/9/20 11:39 AM, David Woodhouse wrote:
>>> As far as I can tell, Xen's hvm_vcpu_has_pending_irq() will still
>>> return the domain-wide vector in prefer
On 12/9/20 11:39 AM, David Woodhouse wrote:
> On Wed, 2020-12-09 at 10:51 +0000, Joao Martins wrote:
>> Isn't this what the first half of this patch was doing initially (minus the
>> irq routing) ? Looks really similar:
>>
>> https://lore.kernel.org/kvm/201
On 12/9/20 10:27 AM, David Woodhouse wrote:
> On Tue, 2020-12-08 at 22:35 -0800, Ankur Arora wrote:
>>> It looks like Linux doesn't use the per-vCPU upcall vector that you
>>> called 'KVM_XEN_CALLBACK_VIA_EVTCHN'. So I'm delivering interrupts via
>>> KVM_INTERRUPT as if they were ExtINT
>>>
On 12/2/20 7:02 PM, David Woodhouse wrote:
> On Wed, 2020-12-02 at 18:34 +0000, Joao Martins wrote:
>> On 12/2/20 4:47 PM, David Woodhouse wrote:
>>> On Wed, 2020-12-02 at 13:12 +, Joao Martins wrote:
>>>> On 12/2/20 11:17 AM, David Woodhouse wrote:
>>>
On 12/2/20 4:47 PM, David Woodhouse wrote:
> On Wed, 2020-12-02 at 13:12 +0000, Joao Martins wrote:
>> On 12/2/20 11:17 AM, David Woodhouse wrote:
>>> I might be more inclined to go for a model where the kernel handles the
>>> evtchn_pending/evtchn_mask for us. What wo
On 12/2/20 11:17 AM, David Woodhouse wrote:
> On Wed, 2019-02-20 at 20:15 +0000, Joao Martins wrote:
>> @@ -176,6 +177,9 @@ int kvm_arch_set_irq_inatomic(struct
>> kvm_kernel_irq_routing_entry *e,
>> int r;
>>
>> switch (e->type) {
>&g
On 12/1/20 11:19 AM, David Woodhouse wrote:
> On Tue, 2020-12-01 at 09:48 +, David Woodhouse wrote:
>> So I switched it to generate the hypercall page directly from the
>> kernel, just like we do for the Hyper-V hypercall page.
>
> Speaking of Hyper-V... I'll post this one now so you can start
On 12/2/20 5:17 AM, Ankur Arora wrote:
> On 2020-12-01 5:26 p.m., David Woodhouse wrote
>> On Tue, 2020-12-01 at 16:40 -0800, Ankur Arora wrote:
>>> On 2020-12-01 5:07 a.m., David Woodhouse wrote:
[...]
If that was allowed, wouldn't it have been a much simpler fix for
CVE-2019-3016? Wha
[late response - was on holiday yesterday]
On 12/2/20 12:40 AM, Ankur Arora wrote:
> On 2020-12-01 5:07 a.m., David Woodhouse wrote:
>> On Wed, 2019-02-20 at 20:15 +0000, Joao Martins wrote:
>>> +static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
>>> +{
>
On 11/30/20 7:04 PM, David Woodhouse wrote:
> On Mon, 2020-11-30 at 18:41 +0000, Joao Martins wrote:
>> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>> {
>> ...
>> if (kvm_hv_hypercall_enabled(vcpu->kvm))
>> return kvm
On 11/30/20 6:01 PM, David Woodhouse wrote:
> On Mon, 2020-11-30 at 17:15 +0000, Joao Martins wrote:
>> On 11/30/20 4:48 PM, David Woodhouse wrote:
>>> On Mon, 2020-11-30 at 15:08 +, Joao Martins wrote:
>>>> On 11/30/20 12:55 PM, David Woodhouse wrote:
>>&
On 11/30/20 4:48 PM, David Woodhouse wrote:
> On Mon, 2020-11-30 at 15:08 +0000, Joao Martins wrote:
>> On 11/30/20 12:55 PM, David Woodhouse wrote:
>>> On Mon, 2020-11-30 at 12:17 +, Joao Martins wrote:
>>>> On 11/30/20 9:41 AM, David Woodhouse wrote:
>>&
On 11/30/20 12:55 PM, David Woodhouse wrote:
> On Mon, 2020-11-30 at 12:17 +0000, Joao Martins wrote:
>> On 11/30/20 9:41 AM, David Woodhouse wrote:
>>> On Wed, 2019-02-20 at 20:15 +, Joao Martins wrote:
>>>> EVTCHNOP_send short-circuiting happens by marking th
On 11/30/20 9:41 AM, David Woodhouse wrote:
> On Wed, 2019-02-20 at 20:15 +0000, Joao Martins wrote:
>> userspace registers a @port to an @eventfd, that is bound to a
>> @vcpu. This information is then used when the guest does an
>> EVTCHNOP_send with a port registered with
On 11/3/20 12:04 PM, David Edmondson wrote:
> The instruction emulator ignores clflush instructions, yet fails to
> support clflushopt. Treat both similarly.
>
> Fixes: 13e457e0eebf ("KVM: x86: Emulator does not decode clflush well")
> Signed-off-by: David Edmondson
On 10/19/20 2:37 PM, Paolo Bonzini wrote:
> On 15/10/20 00:25, Dan Williams wrote:
>> Now, with recent device-dax extensions, it
>> also has a coarse grained memory management system for physical
>> address-space partitioning and a path for struct-page-less backing for
>> VMs. What feature gaps re
On 10/10/20 9:15 AM, yulei zhang wrote:
> On Fri, Oct 9, 2020 at 7:53 PM Joao Martins wrote:
>> On 10/9/20 12:39 PM, yulei zhang wrote:
>>> Joao, thanks a lot for the feedback. One more thing needs to mention
>>> is that dmemfs also support fine-grained
>>> m
fine-grained memory management' to understand what is the gap that you mention?
> On Fri, Oct 9, 2020 at 3:01 AM Joao Martins wrote:
>>
>> [adding a couple folks that directly or indirectly work on the subject]
>>
>> On 10/8/20 8:53 AM, yulei.ker...@gmail.com wrote:
&
On 10/9/20 1:58 AM, Sean Christopherson wrote:
> On Thu, Oct 08, 2020 at 03:54:12PM +0800, yulei.ker...@gmail.com wrote:
>> From: Yulei Zhang
>>
>> Dmem page is pfn invalid but not mmio. Support cacheable
>> dmem page for kvm.
>>
>> Signed-off-by: Chen Zhuo
>> Signed-off-by: Yulei Zhang
>> ---
>
[adding a couple folks that directly or indirectly work on the subject]
On 10/8/20 8:53 AM, yulei.ker...@gmail.com wrote:
> From: Yulei Zhang
>
> In current system each physical memory page is assocaited with
> a page structure which is used to track the usage of this page.
> But due to the memo
On 9/25/20 10:01 PM, Dan Williams wrote:
> On Fri, Sep 25, 2020 at 1:52 PM Joao Martins
> wrote:
>>
>> Hey Dan,
>>
>> On 9/25/20 8:11 PM, Dan Williams wrote:
>>> Changes since v4 [1]:
>>> - Rebased on
>>> device-dax-move-instance-creatio
Hey Dan,
On 9/25/20 8:11 PM, Dan Williams wrote:
> Changes since v4 [1]:
> - Rebased on
> device-dax-move-instance-creation-parameters-to-struct-dev_dax_data.patch
> in -mm [2]. I.e. patches that did not need fixups from v4 are not
> included.
>
> - Folded all fixes
>
Hmm, perhaps you mis
mmu_activate_guest_mode().
> Otherwise, this could trigger IO_PAGE_FAULT for the VFIO based VMs with
> AVIC enabled.
>
> Reported-by: Maxim Levitsky
> Tested-by: Maxim Levitsky
> Cc: Joao Martins
> Fixes: e52d58d54a321 ("iommu/amd: Use cmpxchg_double() when updating 128-
On 9/15/20 1:30 PM, Suravee Suthikulpanit wrote:
> On 9/15/20 6:25 PM, Maxim Levitsky wrote:
>> On Mon, 2020-09-14 at 21:48 +0700, Suravee Suthikulpanit wrote:
>>> Could you please try with the following patch instead?
>>>
>>> --- a/drivers/iommu/amd/iommu.c
>>> +++ b/drivers/iommu/amd/iommu.c
>>>
@valid assignment to after @entry has been checked
for NULL.
Cc: Suravee Suthikulpanit
Fixes: 26e495f34107 ("iommu/amd: Restore IRTE.RemapEn bit after programming
IRTE")
Reported-by: Dan Carpenter
Signed-off-by: Joao Martins
---
drivers/iommu/amd/iommu.c | 4 +++-
1 file changed, 3 inse
[Sorry for the late response]
On 8/21/20 11:06 AM, David Hildenbrand wrote:
> On 03.08.20 07:03, Dan Williams wrote:
>> @@ -37,109 +45,94 @@ int dev_dax_kmem_probe(struct device *dev)
>> * could be mixed in a node with faster memory, causing
>> * unavoidable performance issues.
>>
ixes: 880ac60e2538 ("iommu/amd: Introduce interrupt remapping ops structure")
?
> Reported-by: Sean Osborne
> Tested-by: Erik Rockstrom
> Signed-off-by: Suravee Suthikulpanit
With the comments below addressed, FWIW:
Reviewed-by: Joao Martins
> diff --git a/drivers/iommu/amd/init
ffinity() hook to
setup vapic
mode for pass-through devices")
?
> Signed-off-by: Suravee Suthikulpanit
FWIW,
Reviewed-by: Joao Martins
On 7/16/20 5:00 PM, Dan Williams wrote:
> On Thu, Jul 16, 2020 at 6:19 AM Joao Martins
> wrote:
>> On 7/12/20 5:28 PM, Dan Williams wrote:
>>> In support of interrogating the physical address layout of a device with
>>> dis-contiguous ranges, introduce a sysf
Introduce a new module parameter for dax_hmem which
initializes all region devices as free, rather than allocating
a pagemap for the region by default.
All hmem devices created with dax_hmem.region_idle=1 will have full
available size for creating dynamic dax devices.
Signed-off-by: Joao Martins
to 1G. So, we
validate all ranges against the new value being attempted,
post resizing.
Signed-off-by: Joao Martins
---
drivers/dax/bus.c | 101 +-
1 file changed, 92 insertions(+), 9 deletions(-)
diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
Introduce @align to struct dev_dax.
When creating a new device, we still initialize to the default
dax_region @align. Child devices belonging to a region may wish
to keep a different alignment property instead of a global
region-defined one.
Signed-off-by: Joao Martins
---
drivers/dax/bus.c
s use.
[0]
https://lore.kernel.org/linux-mm/159457116473.754248.7879464730875147365.st...@dwillia2-desk3.amr.corp.intel.com
Joao
Joao Martins (4):
device-dax: Make align a per-device property
device-dax: Add an 'align' attribute
dax/hmem: Introduce dax_hmem.region_idle parameter
dev
fast restart[0] where after kexec we
want to the same gpa<->phys mappings (as originally created
before kexec).
[0]
https://static.sched.com/hosted_files/kvmforum2019/66/VMM-fast-restart_kvmforum2019.pdf
Signed-off-by: Joao Martins
---
drivers/dax/bus.c | 64 +
On 7/12/20 5:28 PM, Dan Williams wrote:
> In support of interrogating the physical address layout of a device with
> dis-contiguous ranges, introduce a sysfs directory with 'start', 'end',
> and 'page_offset' attributes. The alternative is trying to parse
> /proc/iomem, and that file will not refle
On 3/23/20 11:55 PM, Dan Williams wrote:
> @@ -561,13 +580,26 @@ static int __alloc_dev_dax_range(struct dev_dax
> *dev_dax, u64 start,
> if (start == U64_MAX)
> return -EINVAL;
>
> + ranges = krealloc(dev_dax->ranges, sizeof(*ranges)
> + * (dev_dax->n
On 10/17/19 8:20 PM, Rafael J. Wysocki wrote:
> On Thu, Oct 17, 2019 at 2:41 AM Zhenzhong Duan
> wrote:
>> and haltpoll
>> is built in. If haltpoll is built as a module, still give a chance for
>> admin to use it despite 'idle='.
>
> Why exactly? Do you have any particular use case in mind?
>
T
4.
Joao Martins (4):
cpuidle: allow governor switch on cpuidle_register_driver()
cpuidle-haltpoll: set haltpoll as preferred governor
cpuidle-haltpoll: return -ENODEV on modinit failure
cpuidle-haltpoll: do not set an owner to allow modunload
drivers/cpuidle/cpuidle-haltpoll.c | 4
unloaded later, which makes the
module_exit callback entirely unused. Thus remove the @owner and allow
module to be unloaded.
Fixes: fa86ee90eb11 ("add cpuidle-haltpoll driver")
Signed-off-by: Joao Martins
---
v2:
* Added Fixes tag
---
drivers/cpuidle/cpuidle-haltpoll.c | 1 -
1 file
1 - 100 of 250 matches
Mail list logo
