- 17 8月, 2011 1 次提交
-
-
由 Jan Beulich 提交于
The order-based approach is not only less efficient (requiring a shift and a compare, typical generated code looking like this mov eax, [machine_to_phys_order] mov ecx, eax shr ebx, cl test ebx, ebx jnz ... whereas a direct check requires just a compare, like in cmp ebx, [machine_to_phys_nr] jae ... ), but also slightly dangerous in the 32-on-64 case - the element address calculation can wrap if the next power of two boundary is sufficiently far away from the actual upper limit of the table, and hence can result in user space addresses being accessed (with it being unknown what may actually be mapped there). Additionally, the elimination of the mistaken use of fls() here (should have been __fls()) fixes a latent issue on x86-64 that would trigger if the code was run on a system with memory extending beyond the 44-bit boundary. CC: stable@kernel.org Signed-off-by: NJan Beulich <jbeulich@novell.com> [v1: Based on Jeremy's feedback] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 05 8月, 2011 4 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
with CONFIG_XEN and CONFIG_FTRACE set we get this: arch/x86/xen/trace.c:22: error: ‘__HYPERVISOR_console_io’ undeclared here (not in a function) arch/x86/xen/trace.c:22: error: array index in initializer not of integer type arch/x86/xen/trace.c:22: error: (near initialization for ‘xen_hypercall_names’) arch/x86/xen/trace.c:23: error: ‘__HYPERVISOR_physdev_op_compat’ undeclared here (not in a function) Issue was that the definitions of __HYPERVISOR were not pulled if CONFIG_XEN_PRIVILEGED_GUEST was not set. Reported-by: NRandy Dunlap <rdunlap@xenotime.net> Acked-by: NRandy Dunlap <rdunlap@xenotime.net> Acked-by: NIngo Molnar <mingo@elte.hu> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Igor Mammedov 提交于
WARN message should not complain "Failed to release memory %lx-%lx err=%d\n" ^^^^^^^ about range when it fails to release just one page, instead it should say what pfn is not freed. In addition line: printk(KERN_INFO "xen_release_chunk: looking at area pfn %lx-%lx: " ... printk(KERN_CONT "%lu pages freed\n", len); will be broken if WARN in between this line is fired. So fix it by using a single printk for this. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Igor Mammedov 提交于
Use correct format specifier for unsigned long. Signed-off-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Jeremy Fitzhardinge 提交于
Apparently we wanted CONFIG_FTRACE rather the CONFIG_FUNCTION_TRACER. Reported-by: NSander Eikelenboom <linux@eikelenboom.it> Tested-by: NSander Eikelenboom <linux@eikelenboom.it> Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 26 7月, 2011 1 次提交
-
-
由 Jeremy Fitzhardinge 提交于
When CONFIG_FUNCTION_TRACER is disabled, compilation fails as follows: CC arch/x86/xen/setup.o In file included from arch/x86/include/asm/xen/hypercall.h:42, from arch/x86/xen/setup.c:19: include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list include/trace/events/xen.h:31: warning: its scope is only this definition or declaration, which is probably not what you want include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list include/trace/events/xen.h:31: warning: 'struct multicall_entry' declared inside parameter list [...] arch/x86/xen/trace.c:5: error: '__HYPERVISOR_set_trap_table' undeclared here (not in a function) arch/x86/xen/trace.c:5: error: array index in initializer not of integer type arch/x86/xen/trace.c:5: error: (near initialization for 'xen_hypercall_names') arch/x86/xen/trace.c:6: error: '__HYPERVISOR_mmu_update' undeclared here (not in a function) arch/x86/xen/trace.c:6: error: array index in initializer not of integer type arch/x86/xen/trace.c:6: error: (near initialization for 'xen_hypercall_names') Fix this by making sure struct multicall_entry has a declaration in scope at all times, and don't bother compiling xen/trace.c when tracing is disabled. Reported-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
- 19 7月, 2011 14 次提交
-
-
由 Jeremy Fitzhardinge 提交于
The CPU would prefer small offsets. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Singleton calls seem to end up being pretty common, so just directly call the hypercall rather than going via multicall. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
It's useful - and probably should be a config - but its very heavyweight, especially with the tracing stuff to help sort out problems. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Make sure the fastpath code is inlined. Batch the page permission change and the pin/unpin, and make sure that it can be batched with any adjacent set_pte/pmd/etc operations. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Remove debugfs stats to make way for tracing. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
- 12 7月, 2011 1 次提交
-
-
由 Raghavendra D Prabhu 提交于
Removing __init from check_platform_magic since it is called by xen_unplug_emulated_devices in non-init contexts (It probably gets inlined because of -finline-functions-called-once, removing __init is more to avoid mismatch being reported). Signed-off-by: NRaghavendra D Prabhu <rprabhu@wnohang.net> Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 30 6月, 2011 1 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
Simple enough - we use an extern defined symbol which is not defined when CONFIG_SMP is not defined. This fixes the linker dying. CC: stable@kernel.org Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 17 6月, 2011 1 次提交
-
-
由 Konrad Rzeszutek Wilk 提交于
The earlier attempts (24bdb0b6) at fixing this problem caused other problems to surface (PV guests with no PCI passthrough would have SWIOTLB turned on - which meant 64MB of precious contingous DMA32 memory being eaten up per guest). The problem was: "on xen we add an extra memory region at the end of the e820, and on this particular machine this extra memory region would start below 4g and cross over the 4g boundary: [0xfee01000-0x192655000) Unfortunately e820_end_of_low_ram_pfn does not expect an e820 layout like that so it returns 4g, therefore initial_memory_mapping will map [0 - 0x100000000), that is a memory range that includes some reserved memory regions." The memory range was the IOAPIC regions, and with the 1-1 mapping turned on, it would map them as RAM, not as MMIO regions. This caused the hypervisor to complain. Fortunately this is experienced only under the initial domain so we guard for it. Acked-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 16 6月, 2011 2 次提交
-
-
由 Tom Goetz 提交于
.. As it won't actually power off the machine. Reported-by: NSven Köhler <sven.koehler@gmail.com> Tested-by: NSven Köhler <sven.koehler@gmail.com> Signed-off-by: NTom Goetz <tom.goetz@virtualcomputer.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Andrew Jones 提交于
The MAXSMP config option requires CPUMASK_OFFSTACK, which in turn requires we init the memory for the maps while we bring up the cpus. MAXSMP also increases NR_CPUS to 4096. This increase in size exposed an issue in the argument construction for multicalls from xen_flush_tlb_others. The args should only need space for the actual number of cpus. Also in 2.6.39 it exposes a bootup problem. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff8157a1d3>] set_cpu_sibling_map+0x123/0x30d ... Call Trace: [<ffffffff81039a3f>] ? xen_restore_fl_direct_reloc+0x4/0x4 [<ffffffff819dc4db>] xen_smp_prepare_cpus+0x36/0x135 .. CC: stable@kernel.org Signed-off-by: NAndrew Jones <drjones@redhat.com> [v2: Updated to compile on 3.0] [v3: Updated to compile when CONFIG_SMP is not defined] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 09 6月, 2011 1 次提交
-
-
由 Stefano Stabellini 提交于
We only need to set max_pfn_mapped to the last pfn mapped on x86_64 to make sure that cleanup_highmap doesn't remove important mappings at _end. We don't need to do this on x86_32 because cleanup_highmap is not called on x86_32. Besides lowering max_pfn_mapped on x86_32 has the unwanted side effect of limiting the amount of memory available for the 1:1 kernel pagetable allocation. This patch reverts the x86_32 part of the original patch. CC: stable@kernel.org Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 06 6月, 2011 1 次提交
-
-
由 Jeremy Fitzhardinge 提交于
Get the information about the VGA console hardware from Xen, and put it into the form the bootloader normally generates, so that the rest of the kernel can deal with VGA as usual. [ Impact: make VGA console work in dom0 ] Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> [v1: Rebased on 2.6.39] [v2: Removed incorrect comments and fixed compile warnings] Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
- 04 6月, 2011 1 次提交
-
-
由 Dan Carpenter 提交于
b->args[] has MC_ARGS elements, so the comparison here should be ">=" instead of ">". Otherwise we read past the end of the array one space. CC: stable@kernel.org Signed-off-by: NDan Carpenter <error27@gmail.com> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
- 21 5月, 2011 9 次提交
-
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
To make way for tracing. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
We no longer support HIGHPTE allocations, so ptes should always be within the kernel's direct map, and don't need pagetable walks to convert to machine addresses. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
xen_set_pte_at and xen_clear_pte are essentially identical to xen_set_pte, so just make them all common. When batched set_pte and pte_clear are the same, but the unbatch operation must be different: they need to update the two halves of the pte in different order. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
In principle update_va_mapping is a good match for set_pte_at, since it gets the address being mapped, which allows Xen to use its linear pagetable mapping. However that assumes that the pmd for the address is attached to the current pagetable, which may not be true for a given user address space because the kernel pmd is not shared (at least on 32-bit guests). Normally the kernel will automatically sync a missing part of the pagetable with the init_mm pagetable transparently via faults, but that fails when a missing address is passed to Xen. And while the linear pagetable mapping is very useful for 32-bit Xen (as it avoids an explicit domain mapping), 32-bit Xen is deprecated. 64-bit Xen has all memory mapped all the time, so it makes no real difference. The upshot is that we should use mmu_update, since it can operate on non-current pagetables or detached pagetables. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
由 Jeremy Fitzhardinge 提交于
Xen can work out when we're doing IO mappings for itself, so we don't need to do anything special, and the extra tests just clog things up. Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-
- 19 5月, 2011 3 次提交
-
-
由 Daniel Kiper 提交于
Cleanup code/data sections definitions accordingly to include/linux/init.h. Signed-off-by: NDaniel Kiper <dkiper@net-space.pl> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Daniel Kiper 提交于
Cleanup code/data sections definitions accordingly to include/linux/init.h. Signed-off-by: NDaniel Kiper <dkiper@net-space.pl> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
由 Daniel Kiper 提交于
Cleanup code/data sections definitions accordingly to include/linux/init.h. Signed-off-by: NDaniel Kiper <dkiper@net-space.pl> Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-