search for: autotransl

1 / 2 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Renato, If one creates an HVM domain (say domain 1) and then does echo 1 > /dev/oprofile/passive_domains one then gets the following on the Xen serial console: (XEN) xenoprof.c:143:d0 xenoprof/x86 with autotranslated mode enabledisn''t supported yet (XEN) xenoprof.c:143:d0 xenoprof/x86 with autotranslated mode enabledisn''t supported yet (XEN) xenoprof.c:143:d0 xenoprof/x86 with autotranslated mode enabledisn''t supported yet (XEN) xenoprof.c:143:d0 xenoprof/x86 with autotranslate...

These mappings are in fact special and require special handling in privcmd, which already exists. Failure to mark the PTE as special on arm64 causes all sorts of bad PTE fun. x86 already gets this correct. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: xen-devel@lists.xenproject.org --- arch/arm/xen/enlighten.c |

...pud/pmd/pte pages. >> >> Linux/ia64 resolves faults on the area [PAGE_OFFSET, ...] >> by tlb insert without init_mm traverse after checking >> faulted virtual address and its privilege. > >Okay, but the ia64 ifdefs are unfortunate. Your new scheme will work >for x86 autotranslated guests too (I''m pretty sure). How about we pick >between the two schemes based on the autotranslate feature flag rather >than ''ifdef ia64''? > > -- Keir > Yes, that''s desired way. Now IA64 scheme is pretty similar to auto translated x86 mode...

Grant references for the xenstore and xenconsole shared pages exist, but currently only xenstore uses these references. Change the xenconsole daemon to prefer using the grant reference over map_foreign_range when mapping the shared console ring. This allows xenconsoled to be run in a domain other than dom0 if set up correctly - for libxl, the xenstore path /tool/xenconsoled/domid specifies the

..._ops to __generic_dma_ops; - call __generic_dma_ops(hwdev)->alloc/free on arm64 too; - introduce xen_dma_map/unmap_page and xen_dma_sync_single_for_cpu/device; - use xen_dma_map/unmap_page, xen_dma_sync_single_for_cpu/device in swiotlb-xen; - use dev_warn instead of pr_warn; - remove the extra autotranslate check in biomerge.c; - call set_phys_to_machine after mapping grant refs in gnttab_map_refs; - call set_phys_to_machine after unmapping grant refs in gnttab_unmap_refs; - allow __set_phys_to_machine to be called for autotranslate guests on x86. Changes in v6: - check for dev->dma_mask bein...

hi I try to understand the code of xen memory there are gmfn, gpfn and pfn in the xen and in the /xen/include/xen/mm.h there are some explanation about them as follows: * 1. gpfn/gpaddr: A guest-specific pseudo-physical frame number or address. * 2. gmfn/gmaddr: A machine address from the p.o.v. of a particular guest. * 3. mfn/maddr: A real machine frame number or address. * 4.

...LED xen: remove deprecated IRQF_DISABLED Paul Gortmaker (1): xen: delete new instances of added __cpuinit Stefano Stabellini (23): arm: make SWIOTLB available arm64: define DMA_ERROR_CODE arm/xen,arm64/xen: introduce p2m xen/x86: allow __set_phys_to_machine for autotranslate guests xen: make xen_create_contiguous_region return the dma address xen/arm,arm64: enable SWIOTLB_XEN swiotlb-xen: introduce xen_swiotlb_set_dma_mask arm/xen: get_dma_ops: return xen_dma_ops if we are running as xen_initial_domain arm64/xen: get_dma_ops: return xen...

Hi, V6: The only change from V5 is in patch #6: - changed comment to reflect autoxlate - removed a redundant ASSERT - reworked logic a bit so that get_page_from_gfn() is called with NULL for p2m type as before. arm has ASSERT wanting it to be NULL. Tim: patch 4 needs your approval. Daniel: patch 5 needs your approval. These patches implement PVH dom0. Patches 1 and 2

Hi, I have a question about memory page tables in Xen. As far as I understood, every modification to page table will go through Xen(hypervisor). Is it so that all page tables are actually allocated in Xen(hypervisor) instead of guest OS(domain)? Also, is it the case that Xen(hypervisor) needs to maintain a page table for each process running in every domain? Thanks Haifeng

Changes from v3: - mini-os configuration files moved into stubdom/ - mini-os extra console support now a config option - Fewer #ifdefs - grant table setup uses hypercall bounce - Xenstore stub domain syslog support re-enabled Changes from v2: - configuration support added to mini-os build system - add mini-os support for conditionally compiling frontends, xenbus -

paging mechanism clarification Hi All, The Xen uses 2 level Paging Mechanism to resolve the Virtual Addresses into frame numbers from domU.The first level is taken care by the MMU for the domU i.e translation from virtual address to the physical address just like normal paging mechanism. The second level of translation is done by the Xen hypervisor.It translates the pseduo physical address