similar to: read_pci_config() in dom0 in x86_64?

Does Xen 3.0.0 actually support the IOMMU on x86_64? I''ve tried building with a couple of different configurations, and it always fails if I''ve enabled CONFIG_GART_IOMMU. The problems center around undefined references to functions such as dma_alloc_coherent, dma_free_coherent, iommu_setup, iommu_hole_init, force_iommu, iommu_aperture_allowed, and so on. In all cases, changing

These are the diffs against the pristine versions of arch/x86_64/kernel/[aperture.c,pci-gart.c] to better show the changes necessary to adapt those files to Xen. They were included with the patch and should not be applied again. -Mark Langsdorf AMD, Inc. --- pristine-linux-2.6.12/arch/x86_64/kernel/aperture.c 2005-06-17 12:48:29.000000000 -0700 +++

Oh, thanks, Niraj. I overlooked this initially, because this code is not implemented in waldi 3.1-2 kernel, but only in 3.3-1. I''ll check it out tonight, as booting a new kernel per remote is a bit too dangerous. This would be exactly what I need. BR, Carsten. Von: Niraj Tolia Gesendet: Mit, 7.1.2009 22:53 An: Carsten Schiers Cc: jbeulich ; mark.langsdorf ; xen-devel Betreff:

Modify the cpufreq ondemand governor so that it can get idle and total nsecs from the Xen hypervisor.  Xen uses nsecs to measure idle time, while Linux uses ticks. Other than accounting for that difference, use the same algorithm to calculate idle time as Linux does. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> diff -r 26962454b508 drivers/cpufreq/cpufreq_ondemand.c ---

Now if VT-d is enabled, when Dom0 does S3, Xen doesn''t suspend/resume the IOMMU states. The patch adds the missing invocations of iommu_suspend()/iommu_resume() and makes some nesessary fixes: 1) In iommu_set_root_entry(), we should not re-allocate the root-entry when Xen returns from S3; 2) Define the array iommu_state correctly (u8 -> u32); 3) Only save/restore the necessary IOMMU

Processing commands for control at bugs.debian.org: > reassign 603727 linux-2.6 Bug #603727 [xen-hypervisor-4.0-amd64] xen-hypervisor-4.0-amd64: i386 Dom0 crashes after doing some I/O on local storage (software Raid1 on SAS-drives with mpt2sas driver) Bug reassigned from package 'xen-hypervisor-4.0-amd64' to 'linux-2.6'. No longer marked as found in versions xen/4.0.1-1.

Hi all, I follow instructions(http://wiki.xensource.com/xenwiki/XenParavirtOps) to build XEN and dom0 kernel. Building XEN has no problem, but there is an error which I cannot solve to build dom0 kernel. The brief instructions for building dom0 are get linux-2.6-xen code from git and make ARCH=x86_64 menuconfig, finally generate kernel.deb. (I did every step exactly as the web page says)

OK, cut two of the iommu reserved memory issue patch as we discussed... This patch adds a boolean boot parameter to xen to allow inclusive mapping of all memory below 4GB to the iommu mappings for dom0. The unusable ranges and memory occupied by xen are still excluded. The parameter is "iommu_inclusive_mapping=1" and is off by default. In addition to the parameter, a warning is also

Hi, I am trying to get X to work on Xen Dom0 running a custom 3.4.10 kernel. with a Nvidia Gt220 card + 295.59 drivers.Although,the drivers get loaded and X starts,but after some time its seems to get stuck in some kind of infinite loop and starts taking up 100 % cpu. This is observed only when i boot up the machine with the Xen hypervisor,otherwise X works well with out the hypervisor being

Enable cpufreq support in Xen for AMD Operton processors by: 1) Allowing the PowerNow! driver in dom0 to write to the PowerNow! MSRs. 2) Adding the cpufreq notifier chain to time-xen.c in dom0. On a frequency change, a platform hypercall is performed to scale the frequency multiplier in the hypervisor. 3) Adding a platform hypercall to the hypervisor the scale the frequency multiplier and reset

On Thu, 30 Sep 2010 14:02:34 +0800, gang.wei@intel.com wrote: > I am the original developer of HPET broadcast code. > > First of all, to disable HPET broadcast, no additional patch is required. > Please simply add option "cpuidle=off" or "max_cstate=1" at xen cmdline in > /boot/grub/grub.conf. > > Second, I noticed that the issue just occur on

There is a missing } in one of the patches for drivers/char/agp/intel-agp.c:intel_agp_insert_sg_entries() in xen.git. The diff I get looks like this: --- linux-2.6.32/drivers/char/agp/intel-agp.c +++ linux-2.6-jeremy-xen-stable-2.6.32.x/drivers/char/agp/intel-agp.c @@ -10,14 +10,20 @@ #include <linux/agp_backend.h> #include <asm/smp.h> #include "agp.h" +#include

I previously sent this help request to xen-api rather than xen-users. My apologies for the re-send. ------------------- I am following http://www.gentoo.org/doc/en/xen-guide.xml to build a new box for use as dom0. For the dom0 kernel configu I used as a basis a previous, working config from a non-xen kernel. That previous kernel (2.6.32-gentoo-r7) exhibits no console video problem. My new xen

Hello, People here might be interested to know that Xen pvops dom0 core was merged to upstream Linux kernel during the 2.6.37 merge window! This has been in the works for a long time, so it's good news. Note that this is the core/initial merge, there's more upstreaming needed to get for example the Xen dom0 backend drivers merged to be able to run other domains using the upstream

Testing by Red Hat show that changeset:0034d9389130 causes regressions on Intel machines that don''t use APIC ID lifting but that do have a strange ACPI to APIC numbering. Modify the patch so that it only applies to AMD machines. -Mark Langsdorf Operating System Research Center AMD Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> diff -r 49ffe9ef67d4

Package: xen-hypervisor-4.4-amd64 Version: 4.4.1-9 On a fresh installation of Debian Jessie, when I try to start a domU, it try to access to a dom0 LVM Volume Group : [...] (I put all the boot at the end) Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Begin: Assembling all MD

Hello all, My machine is a dual xeon x5520 server with NUMA support. I have some question about xen dom0 kernel. Since xen hypervisor has provided vcpu schedule, do we need to compile the following feature in dom0 kernel? - Tickless System (Dynamic Ticks) - High Resolution Timer Support - AMD IOMMU support - SMT (Hyperthreading) scheduler support - Multi-core scheduler suppor

Greeted by a blank screen when X starts when booting Dom0. Booting without Dom0, X starts. Have tried latest official, beta, and elrepo fglrx drivers with the same result. Kernel version is 3.4.53-8.el6.x86_64. Xorg: Xorg-1.13.0-11 Xen version is 4.2.3. Device: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler XT [AMD Radeon HD 6700M Series]. I noticed a series

There are 4 picture galleries with a total of 176 png image screenshots. Picture Tutorial 1 of 4: Installing OpenSUSE 11.2 x86_64 Linux as a PV DomU (Xen 3.5-unstable Pv-Ops Dom0 Kernel 2.6.31.5)Link: http://enmingteo.wordpress.com/2009/11/13/picture-tutorial-1-of-4-installing-opensuse-11-2-x86_64-linux-as-a-pv-domu-xen-3-5-unstable-pv-ops-dom0-kernel-2-6-31-5/ *Picture Tutorial 2 of 4:

I started a new thread because this not a pv-ops dom0 anymore. I''m running Andrew Lyon''s 2.6.31-4 patches for a non-pv-ops kernel. Got it again, after issuing "poweroff" from the domU. (XEN) (XEN) NMI - MEMORY ERROR (XEN) ----[ Xen-3.5-unstable x86_64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<ffff82c48011f55c>] remove_from_heap+0x8f/0xd0