From mboxrd@z Thu Jan  1 00:00:00 1970
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: L1[0x1fb] = 0000000000000000 which faults on one
	type of machine but on another works?
Date: Thu, 17 Mar 2011 12:41:43 -0400
Message-ID: <20110317164143.GA26392@dumpdata.com>
References: <20110316221912.GA13035@dumpdata.com>
	<4D81EF97020000780003706E@vpn.id2.novell.com>
	<20110317155211.GA29603@dumpdata.com>
	<4D82411002000078000371D8@vpn.id2.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <xen-devel-bounces@lists.xensource.com>
Content-Disposition: inline
In-Reply-To: <4D82411002000078000371D8@vpn.id2.novell.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jan Beulich <JBeulich@novell.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com, andrew.thomas@oracle.com, Ian Campbell <Ian.Campbell@eu.citrix.com>, keir.xen@gmail.com, swente@infinitumb.de, gianni.tedesco@citrix.com
List-Id: xen-devel@lists.xenproject.org

On Thu, Mar 17, 2011 at 04:12:48PM +0000, Jan Beulich wrote:
> >>> On 17.03.11 at 16:52, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 2.6.38 fixes this by allowing in acpi_register_lapic_address, the
> > the set_fixmap_nocache(FIX_APIC_BASE, address) to be called and we
> > can provide it with a dummy page and native_apic_read can happily
> > read from that fake page.
> 
> I wonder whether that's going to be appropriate in cases...

If you boot the 2.6.38 it works, but it does provide these ugly and untrue values:

   0.000000] ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 15, version 255, address 0xfec00000, GSI 0-255
[    0.000000] ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[36])
[    0.000000] IOAPIC[1]: apic_id 14, version 255, address 0xfec01000, GSI 36-291
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] Int: type 0, pol 0, trig 0, bus 00, IRQ 00, APIC ID f, APIC INT 02
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 8 low edge)
[    0.000000] Int: type 0, pol 3, trig 1, bus 00, IRQ 08, APIC ID f, APIC INT 08
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 low edge)
[    0.000000] Int: type 0, pol 3, trig 1, bus 00, IRQ 0e, APIC ID f, APIC INT 0e
[    0.000000] Int: type 0, pol 3, trig 3, bus 00, IRQ 09, APIC ID f, APIC INT 09
[    0.000000] ACPI: IRQ0 used by override.

I don't remember if it was suggested to hpa/ingo/tglx whether we could
provide another 'struct apic' that would be Xen specific and the apic->probe()
would either provide a struct mostly filled with dummy functions that return
nothing, or the Xen apic->probe() function would over-write the current
'apic->read,write, etc' with the xen dummy functions.

However we seem to achieve this already by providing a dummy page that 
is read/writen to by the native_apic_[read|write].