similar to: [PATCH] minios: fix p2m on x86

This patch series contains a set of patches making minios rather easier to use, from an application development point of view. Overview of patches: 1 Command line argument parsing support, from Xen. 2 Weak console handler function. 3 Build system tweaks for application directories. 4 Trailing whitespace cleanup. (because it is very messy) Patch 4 is likely to be more controversial than

This patch worked on top of paging interface patches posted today. It create common interface for P2M table, which handles guest physical address to machine physical address translation. Tested on the following platforms: 1. AMD SVM boxes * 64-bit Xen: 32-bit WinXP SP2, 32-bit SUSE10, 32-bit SUSE 10 PAE BigSMP, and 64-bit RHEL4 * 32-bit PAE Xen: 32-bit WinXP SP2, 32-bit SUSE10, 32-bit SUSE 10

We would the full P2M top directory from 0->MAX_DOMAIN_PAGES (inclusive). Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512 we would try to use the 512th entry. Fortunately for us the p2m_top_index has a check for this: BUG_ON(pfn >= MAX_P2M_PFN); which we hit and saw this: (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: (XEN)

Hello, how can a gfn become 0x555555 as checked in p2m.c:guest_physmap_add_entry() and p2m_alloc_table()? Looking further in p2m.c, audit_p2m() checks only for a 32bit value. So where is that magic number set, and why is it not a define to simplify grepping for users of that value? Olaf _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com

Commit 90805dc (c/s 26387:4056e5a3d815) ("EPT: Make ept data stucture or operations neutral") makes nested p2m tables be unlinked from the host p2m table before their destruction (in p2m_teardown_nestedp2m). However, by this time the host p2m table has already been torn down, leading to a possible race condition where another allocation between the two kinds of table being torn down can

build p2m mapping according to m2p mapping. Signed-off-by: Xin Li <xin.b.li@intel.com> Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

In p2m.c (line 197 and line 550), the code assumes the number of L3 P2M table entries is 8 (under PAE mode). According to Intel and AMD specs, it is 4. Could someone explain this discrepancy? Is it a bug? -Wei _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

In commit cd9151e2: xen/balloon: set a mapping for ballooned out pages we have the ballooned out page''s mapping set to a scratch page. That commit also sets the P2M entry of ballooned out page to the scratch page''s MFN. This is necessary for PV guest but not for HVM guest. On the other hand, setting the P2M entry would trigger BUG_ON in __set_phys_to_machine. The correct thing

Hi! Attached patch removes gfn_to_mfn_current(). It is redundant and effectively unused. All remaining users now use proper replacement function. => No functional change. While here, silence stdvga and use page_mode_hap() consequently. Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH

And can we make p2m memory allocation from domain heap directly? -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Not just dom0. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- xen/arch/arm/domain.c | 3 +++ xen/arch/arm/domain_build.c | 3 --- xen/arch/arm/p2m.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c index 5702399..4b38790 100644 --- a/xen/arch/arm/domain.c +++ b/xen/arch/arm/domain.c @@

Hi Xen developers and enthousiasts, Recently I have been having a lot of problems with HVM hosts on a dual Xeon E5606 box. Problem is that HVM hosts don''t work on it at all and crash the server. Today I got the logging to work over an IPMI console so then I compiled a fresh xen-unstable. Apart from the message I posted in the subject the call trace reads as follows: (XEN) Xen call

-- Advanced Micro Devices GmbH Sitz: Dornach, Gemeinde Aschheim, Landkreis München Registergericht München, HRB Nr. 43632 WEEE-Reg-Nr: DE 12919551 Geschäftsführer: Alberto Bozzo, Andrew Bowd _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

This patch series tidies up a few bits ofthe nested p2m code. The main thing it does is reorganize the locking so that most of the changes to nested p2m tables happen only under the p2m lock, and the nestedp2m lock is only needed to reassign p2m tables to new cr3 values. Changes since v1: - a few minor fixes - more sensible flushing policy in p2m_get_nestedp2m() - smoke-tested this time!

It's supposed to always be 0, but at least nv_iowr() temporarily violates this. Since the ih touches $r0, it should be stored. Signed-off-by: Roy Spliet <rs855 at cam.ac.uk> --- drm/nouveau/nvkm/engine/gr/fuc/gpc.fuc | 2 + drm/nouveau/nvkm/engine/gr/fuc/gpcgf100.fuc3.h | 80 ++++---- drm/nouveau/nvkm/engine/gr/fuc/gpcgf117.fuc3.h | 82 ++++----