search for: gnttabop_map_grant_ref

This is a cherry pick of two patches that add support for guest paged out frames in the XCP 2.6.32 dom0 patch queue. First patch propagates the ENOENT returned by the hypervisor in the case of a paged out page, all the way up the call chain to the MMAPBATCH_V2 ioctl. The ioctl is mainly used to harvest those return values and retry. The second patch adds retry loops to all backend grant

Patrick, there following patches fix xenpaging for me. Granttable handling is incomplete. If a page is gone, a GNTST_eagain should be returned to the caller to inidcate the hypercall has to be retried after a while, until the page is available again. Please review. Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

...} -static int map_frontend_page(blkif_t *blkif, unsigned long shared_page) -{ - struct gnttab_map_grant_ref op; - int ret; - - gnttab_set_map_op(&op, (unsigned long)blkif->blk_ring_area->addr, - GNTMAP_host_map, shared_page, blkif->domid); - - gnttab_check_GNTST_eagain_do_while(GNTTABOP_map_grant_ref, &op); - - if (op.status == GNTST_okay) { - blkif->shmem_ref = shared_page; - blkif->shmem_handle = op.handle; - ret = 0; - } else { - DPRINTK(" Grant table operation failure %d!\n", (int)op.status); - ret = -EINVAL; - } - - return ret; -} - -static void unmap_frontend_page...

Hi, I am trying to export a memory page of dom0 to a domU in readonly mode. In dom0, I grant access permission to that domU. In domU, I did HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map, res->nr_pages); All these functions returned successfully. But when I tried to access data in the mapped memory page, all data I got is 0. Is there any restriction that preventing dom0 pages from being export to other domains? If so, is there any way to relax this restriction? xin _...

I''m having problems starting more than three domains. It sometimes works fine, but more often than not the 4th domain''s root block device times out and so the domU kernel panics as there''s no /dev/root: XENBUS: Timeout connecting to device: device/vbd/2057 (state 6) XENBUS: Timeout connecting to device: device/vif/0 (state 6) XENBUS: Timeout connecting to device:

...--- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -933,9 +933,6 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, struct page **pages, unsigned int count) { int i, ret; - bool lazy = false; - pte_t *pte; - unsigned long mfn; ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map_ops, count); if (ret) @@ -947,45 +944,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i, &map_ops[i].status, __func__); - /* this is basically a nop on x86 */ - if (xen_feature(XENFEAT_auto_translated_p...

...--- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -933,9 +933,6 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, struct page **pages, unsigned int count) { int i, ret; - bool lazy = false; - pte_t *pte; - unsigned long mfn; ret = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, map_ops, count); if (ret) @@ -947,45 +944,7 @@ int gnttab_map_refs(struct gnttab_map_grant_ref *map_ops, gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, map_ops + i, &map_ops[i].status, __func__); - /* this is basically a nop on x86 */ - if (xen_feature(XENFEAT_auto_translated_p...

...< buffer_num_pages; i++) { printk(KERN_INFO "Mounting GREF %d\n", *grefp); memset(&op, 0, sizeof(op)); op.host_addr = x->buffer_addr + i * PAGE_SIZE; op.flags = GNTMAP_host_map; op.ref = *grefp; op.dom = x->otherend_id; rc = HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1); if (rc == -ENOSYS) { goto err_unmap; } if (op.status) { DPRINTK("error: grant table mapping failed\n"); goto err_unmap; } x->buffer_handles[i] = op.handle; grefp = (int *)(x->buffer_addr + i * PAGE_SIZE); } The mapping...

...(capable of supporting PAE). I''m doing some research into providing grant table hypercall support from a Windows 2003 HVM. I have made all the necessary changes to allow the hypercall to make it into the hypervisor and execute the correct grant table ops. I''m now testing the GNTTABOP_map_grant_ref with the GNTMAP_host_map and it correctly obtains the MFN from the grantor domain. It then attempts to take the HVM host VA address (a windows kernel VA from the non-paged pool) and walk the guest''s page table to obtain the PFN. I am building the hypervisor by simply typing "make xe...

In dispatch_rw_block_io after a call to HYPERVISOR_grant_table_op, there is the following code which calls fast_flush_area and breaks out of the loop early if one of the handles returned from HYPERVISOR_grant_table_op is negative: for (i = 0; i < nseg; i++) { if (unlikely(map[i].handle < 0)) { DPRINTK("invalid buffer -- could not remap it\n"); fast_flush_area(pending_idx,

...refs; i++) { + op[i].flags = GNTMAP_host_map | GNTMAP_contains_pte, + op[i].ref = gnt_ref[i], + op[i].dom = dev->otherend_id, + op[i].host_addr = arbitrary_virt_to_machine(pte[i]).maddr; + }; if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) BUG(); - if (op.status != GNTST_okay) { - free_vm_area(area); - kfree(node); - xenbus_dev_fatal(dev, op.status, - "mapping in shared page %d from domain %d", -...

...refs; i++) { + op[i].flags = GNTMAP_host_map | GNTMAP_contains_pte, + op[i].ref = gnt_ref[i], + op[i].dom = dev->otherend_id, + op[i].host_addr = arbitrary_virt_to_machine(pte[i]).maddr; + }; if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) BUG(); - if (op.status != GNTST_okay) { - free_vm_area(area); - kfree(node); - xenbus_dev_fatal(dev, op.status, - "mapping in shared page %d from domain %d", -...

...refs; i++) { + op[i].flags = GNTMAP_host_map | GNTMAP_contains_pte, + op[i].ref = gnt_ref[i], + op[i].dom = dev->otherend_id, + op[i].host_addr = arbitrary_virt_to_machine(pte[i]).maddr; + }; if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, &op, 1)) BUG(); - if (op.status != GNTST_okay) { - free_vm_area(area); - kfree(node); - xenbus_dev_fatal(dev, op.status, - "mapping in shared page %d from domain %d", -...

Here''s the latest USB code against the xen 3.0.0 release. Since the last posting this version updates the code to use the new 32 bit grant references and the latest GNTTABOP_map_grant_ref definition. I''ve also changed the definition of the virtual USB HCD to have a single port rather than seven ports with six unused. Domains importing multiple USB devices will get a HCD for each device (this feature currently untested). I went with this solution because it scales indefin...

2011/7/19 Stefano Stabellini <stefano.stabellini@eu.citrix.com>: > CC''ing Tim and xen-devel > > On Mon, 18 Jul 2011, Jiageng Yu wrote: >> 2011/7/16 Stefano Stabellini <stefano.stabellini@eu.citrix.com>: >> > On Fri, 15 Jul 2011, Jiageng Yu wrote: >> >> 2011/7/15 Jiageng Yu <yujiageng734@gmail.com>: >> >> > 2011/7/15

Hi all, this patch series enables xen-swiotlb on arm and arm64. It has been heavily reworked compared to the previous versions in order to achieve better performances and to address review comments. We are not using dma_mark_clean to ensure coherency anymore. We call the platform implementation of map_page and unmap_page. We assume that dom0 has been mapped 1:1 (physical address == machine

pvSCSI backend driver Signed-off-by: Tomonari Horikoshi <t.horikoshi@jp.fujitsu.com> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com> ----- Jun Kamada _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. Changes from take 5 are rebased to Linux 2.6.26-rc3, bug fix ivt.S paravirtualization and multi entry point support. I believe these patches can be applied to the linux ia64 repository. This patchset does the followings. - Some preparation work. Mainly importing header files to

Hi. This patchset implements ia64/xen domU support based on ia64/pv_ops frame work which was sent as another patchest. This patchset does the followings. - Some preparation work. Mainly importing header files to define related structures. - Then, define functions related to hypercall which is the way to communicate with Xen hypervisor. - Add some helper functions which is necessary to