search for: page_list

...dbc85..b6d9016 100644 > --- a/drivers/vhost/vdpa.c > +++ b/drivers/vhost/vdpa.c > @@ -588,19 +588,21 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v, > struct vhost_dev *dev = &v->vdev; > struct vhost_iotlb *iotlb = dev->iotlb; > struct page **page_list; > - struct vm_area_struct **vmas; > + unsigned long list_size = PAGE_SIZE / sizeof(struct page *); > unsigned int gup_flags = FOLL_LONGTERM; > - unsigned long map_pfn, last_pfn = 0; > - unsigned long npages, lock_limit; > - unsigned long i, nmap = 0; > + unsigned long npage...

...lags(perm)); } + if (r) + vhost_iotlb_del_range(dev->iotlb, iova, iova + size - 1); return r; } @@ -592,21 +594,19 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v, struct vhost_dev *dev = &v->vdev; struct vhost_iotlb *iotlb = dev->iotlb; struct page **page_list; - unsigned long list_size = PAGE_SIZE / sizeof(struct page *); + struct vm_area_struct **vmas; unsigned int gup_flags = FOLL_LONGTERM; - unsigned long npages, cur_base, map_pfn, last_pfn = 0; - unsigned long locked, lock_limit, pinned, i; + unsigned long map_pfn, last_pfn = 0; + unsigned long np...

...lags(perm)); } + if (r) + vhost_iotlb_del_range(dev->iotlb, iova, iova + size - 1); return r; } @@ -592,21 +594,19 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v, struct vhost_dev *dev = &v->vdev; struct vhost_iotlb *iotlb = dev->iotlb; struct page **page_list; - unsigned long list_size = PAGE_SIZE / sizeof(struct page *); + struct vm_area_struct **vmas; unsigned int gup_flags = FOLL_LONGTERM; - unsigned long npages, cur_base, map_pfn, last_pfn = 0; - unsigned long locked, lock_limit, pinned, i; + unsigned long map_pfn, last_pfn = 0; + unsigned long np...

Hi, I am trying to release domU pages from page_list and xenpage_list after domU shutdown while retaining the rest of the domain information. To achieve this in __domain_finalise_shutdown i call domain_relinquish_resources. This is failing to release pages from page_list for type PGT_l2_page_tables and crashing dom0. To be specific, while testing...

...support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. The most important thing which should be changed in that case is format of page_list array. Xen kexec hypercall requires to alternate physical addresses with virtual ones. This and other required things have not done in that version because I am not sure that solution will be accepted by kexec/kdump maintainers. I hope that this email spark discussion about that topic. Daniel ar...

...support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. The most important thing which should be changed in that case is format of page_list array. Xen kexec hypercall requires to alternate physical addresses with virtual ones. This and other required things have not done in that version because I am not sure that solution will be accepted by kexec/kdump maintainers. I hope that this email spark discussion about that topic. Daniel ar...

...support is ready. Jan Beulich suggested to merge Xen x86 assembler code with baremetal x86 code. This could simplify and reduce a bit size of kernel code. However, this solution requires some changes in baremetal x86 code. The most important thing which should be changed in that case is format of page_list array. Xen kexec hypercall requires to alternate physical addresses with virtual ones. This and other required things have not done in that version because I am not sure that solution will be accepted by kexec/kdump maintainers. I hope that this email spark discussion about that topic. Daniel ar...

On 2020/9/9 ??11:41, Li Qiang wrote: > Free the 'page_list' when the 'npages' is zero. > > Signed-off-by: Li Qiang <liq3ea at 163.com> > --- > drivers/vhost/vdpa.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c > index 3fab94f88894..6a...

All, We met several system failures on different hardware platforms, which are all caused by VT-d fault. err 1: disk is corrupted by VT-d fault on SATA. err 2: Dom0 kernel panics at booting, which is caused VT-d fault on UHCI. err 3, Dom0 complains disk errors while creating HVM guests. The culprit would be changeset 19054 "x86_64: Remove statically-partitioned Xen heap.". Detailed

...644 --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -639,7 +639,7 @@ static int page_make_sharable(struct domain *d, } page_set_owner(page, dom_cow); - d->tot_pages--; + domain_decrease_tot_pages(d, 1); drop_dom_ref = (d->tot_pages == 0); page_list_del(page, &d->page_list); spin_unlock(&d->page_alloc_lock); @@ -680,7 +680,7 @@ static int page_make_private(struct domain *d, struct page_info *page) ASSERT(page_get_owner(page) == dom_cow); page_set_owner(page, d); - if ( d->tot_pages++ == 0 ) + if ( domain...

...ugh putback_lru_page()? > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d82196244340..c7696a2e11c7 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1254,7 +1254,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, > > list_for_each_entry_safe(page, next, page_list, lru) { > if (page_is_file_cache(page) && !PageDirty(page) && > - !isolated_balloon_page(page)) { > + !PageIsolated(page)) { > ClearPageActive(page); > list_move(&page->lru, &clean_pages); > } This looks like the same comment...

...ugh putback_lru_page()? > diff --git a/mm/vmscan.c b/mm/vmscan.c > index d82196244340..c7696a2e11c7 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1254,7 +1254,7 @@ unsigned long reclaim_clean_pages_from_list(struct zone *zone, > > list_for_each_entry_safe(page, next, page_list, lru) { > if (page_is_file_cache(page) && !PageDirty(page) && > - !isolated_balloon_page(page)) { > + !PageIsolated(page)) { > ClearPageActive(page); > list_move(&page->lru, &clean_pages); > } This looks like the same comment...

...ize of kernel code. However, this solution requires some changes in baremetal x86 code. First of all code which establishes transition page table should be moved back from machine_kexec_$(BITS).c to relocate_kernel_$(BITS).S. Another important thing which should be changed in that case is format of page_list array. Xen kexec hypercall requires to alternate physical addresses with virtual ones. These and other required stuff have not been done in that version because I am not sure that solution will be accepted by kexec/kdump maintainers. I hope that this email spark discussion about that topic. Daniel...

...ize of kernel code. However, this solution requires some changes in baremetal x86 code. First of all code which establishes transition page table should be moved back from machine_kexec_$(BITS).c to relocate_kernel_$(BITS).S. Another important thing which should be changed in that case is format of page_list array. Xen kexec hypercall requires to alternate physical addresses with virtual ones. These and other required stuff have not been done in that version because I am not sure that solution will be accepted by kexec/kdump maintainers. I hope that this email spark discussion about that topic. Daniel...

...ize of kernel code. However, this solution requires some changes in baremetal x86 code. First of all code which establishes transition page table should be moved back from machine_kexec_$(BITS).c to relocate_kernel_$(BITS).S. Another important thing which should be changed in that case is format of page_list array. Xen kexec hypercall requires to alternate physical addresses with virtual ones. These and other required stuff have not been done in that version because I am not sure that solution will be accepted by kexec/kdump maintainers. I hope that this email spark discussion about that topic. Daniel...

> > > > > > > > Hi MST, > > > > > > > > I have measured the performance when using a 32K page bitmap, > > > > > > Just to make sure. Do you mean a 32Kbyte bitmap? > > > Covering 1Gbyte of memory? > > Yes. > > > > > > > > > and inflate the balloon to 3GB > > > > of an idle guest

> > > > > > > > Hi MST, > > > > > > > > I have measured the performance when using a 32K page bitmap, > > > > > > Just to make sure. Do you mean a 32Kbyte bitmap? > > > Covering 1Gbyte of memory? > > Yes. > > > > > > > > > and inflate the balloon to 3GB > > > > of an idle guest

...repository will BSOD if the option "Large Send Offload" is changed to disabled or if the driver is disabled. Tracked down the issue via WinDbg – If a buffer is in the free list prior to the function XenNet_RxBufferFree() being called via the function XenNet_RxShutdown() the array fl->page_list[] will be overwritten and the variable page_free will be stepped on. A simple solution, which I have verified is to dispose of the free list buffers (if there are any) by calling the function XenFreelist_Dispose() prior to calling the function XenNet_RxBufferFree() Here’s the fix for the functi...

...e repository will BSOD if the option "Large Send Offload" is changed to disabled or if the driver is disabled. Tracked down the issue via WinDbg – If a buffer is in the free list prior to the function XenNet_RxBufferFree() being called via the function XenNet_RxShutdown() the array fl->page_list[] will be overwritten and the variable page_free will be stepped on. A simple solution, which I have verified is to dispose of the free list buffers (if there are any) by calling the function XenFreelist_Dispose() prior to calling the function XenNet_RxBufferFree() Here’s the fix for the function X...

...t for deflating, because the page has been deleted from the vb-> vb_dev_info->pages, > so, we have to use a struct to save the dequeued pages before calling release_pages_balloon(), struct list_head? I think you can just replace set_page_pfns with list_add(&page->lru, &page_list); > I think a page bitmap is the best struct to save these pages, because it consumes less memory. > And that bitmap should be large enough to save pfn 0 to max_pfn. > > If the above is true, then we are back to the square one. we really need a large page bitmap. Right? > >...