linux-kernel - Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 14 Jun 2009 19:06:43 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Ingo Molnar <mingo@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>
Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's
 no local APIC

On 06/12/09 13:35, Eric W. Biederman wrote:
> Jeremy Fitzhardinge<jeremy@...p.org>  writes:
>
>    
>> Parse the ACPI MADT for I/O APIC information, even if the cpu has no
>> (apparent) local APIC (ie, the CPU's APIC feature flag is clear).
>>
>> In principle, the local APIC and the I/O APIC are distinct (but related)
>> components, which can be independently present.
>>
>> In practice this can happen in a Xen system, where the hypervisor has
>> full control over the local APICs, and delivers interrupts initiated by
>> the I/O APICs via Xen's event channel mechanism.
>>      
>
> Xen  is giving us a semi bogus acpi table?
>    

No, not really.  The guest is reading the real BIOS-provided ACPI 
tables, but Xen is clobbering the APIC feature in CPUID so the virtual 
CPU doesn't appear to have a usable local APIC.  Xen itself doesn't care 
very much about interrupt routing or ACPI, and doesn't make any attempt 
to read or parse the ACPI data itself (except for very basic things like 
the APIC addresses).
> What is the paravirt configuration model with Xen?  Is it documented
> somewhere?
>    

Not very well.  The basic idea is that Xen owns the local apics, and 
does things like vector allocation.  The guest kernel is responsible for 
asking for a vector, and doing the appropriate IO APIC programming, and 
binding that vector to an event channel.  The interrupt is then 
delivered via the normal event channel mechanism already in place to 
deal with all the other event types an unprivileged domain can get.

     J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/