search for: ioapic_write_entri

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

# HG changeset patch # User Ian Campbell <ian.campbell at citrix.com> # Date 1304937815 -3600 # Node ID 35abcbcdf8bcabab6e0bbd929f69b613e167edfd # Parent 4b0692880dfa557d4e1537c7a58c412c1286a416 xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables gcc 4.6 complains: io_apic.c: In function 'restore_IO_APIC_setup':

The iommu is enabled by default when xen is booting and later disabled in iommu_setup() when no iommu is present. But under some circumstances iommu-code can be called before iommu_setup() is processed. If there is no iommu available xen crashes. This can happen for example when panic(...) is called that got introduced with patch "x86-64: detect processors subject to AMD erratum #121 and

Xen is crashing for me since version 4.1.3 during boot on a AMD machine. This happens since patch "x86-64: detect processors subject to AMD erratum #121 and refuse to boot." Instead of the actual panic-message from the patch the following stacktrace appears (i typed it down from screen, so it might contain typos) find_iommu_for_device amd_iommu_ioapic_update_ire timer_interrupt

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine