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 for Android: free password hash cracker in your pocket

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

Message-ID: <4A3BEDD6.6070303@goop.org>
Date:	Fri, 19 Jun 2009 12:58:14 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Len Brown <lenb@...nel.org>, 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>,
	"Nakajima, Jun" <jun.nakajima@...el.com>,
	Keir Fraser <keir.fraser@...citrix.com>
Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's
 no local APIC

On 06/18/09 19:42, Eric W. Biederman wrote:
> Interesting.  Then we need to know what Xen has chosen to do.
> This whole logic of having linux and Xen happen to choose the
> same interrupt handling mode by coincidence that is in use
> right now seems fragile.
>
> Xen runs a timer so I can't see Xen actually leaving the decision
> up to linux.  It certainly doesn't leave the physical versus logical
> mode decision up to linux.
>   

Yes.  And if the chipset does actually rely on programming/configuration
from the DSDT, I guess there could be a problem in principle (I don't
know of any problems in practice).

> Assuming Xen not having the AML interpreter is the right decision.
> I recall from some of the hibernation discussions that ACPI is not an easy
> thing to start/stop on a machine unless it is handled just so.
>
> Which if dom0 is to be redundant/restartable seems to make the
> argument for AML living in Xen.
>   
> Xen has everything except the AML interpreter.
>   

I assume that putting AML into Xen has been considered, but I don't
anything about those deliberations.  Keir? Jun?

>> DomU doesn't know or care about ACPI at all.  There's no reason for it
>> to get any kind of ACPI event.
>>     
>
> Yet at least occasionally Xen fakes up ACPI tables for a guest.
>   

No, it never fakes up an ACPI table.  Privileged domains can see the
real BIOS ACPI tables, but unprivileged PV DomUs can't see anything.

(HVM - fully virtualized - domains get completely faked ACPI, along with
everything else, courtesy of qemu.)

> DomU has to do something to get the mapping, which is what I thought you
> were referring to.
>
> I can believe a Xen dom0 that is the same as domU except with lots
> more hardware.

There isn't really a sharp divide between the two.  At core a dom0 (or
"control domain" as we're beginnging to call it) functions just like a
plain paravirtualized domU domain with some extra privileges.  Among
those privileges is the ability to directly map device memory, perform
pio and bind physical interrupts to event channels.

At the moment a whole pile of disparate things are lumped together into
the initial domain (hence "dom0" - the first domain), which tends to
conflate them in people's minds.  But we're moving towards a model of
disaggregating those functions into separate special-purpose domains,
with a more fine-grained notion of "privileged".

For example, there have been prototypes of "driver domains" floating
around for a while now, where a domain has specific responsibility for a
device or set of devices, and is only allowed to access those particular
hardware resources (this is a lot more convincing with VT-d enabled).

Simiarly, xenstore/xenbus - the system-wide configuration state - can be
in its own domain, as it is one of the few things whose loss can't be
recovered from.

>   I have trouble understanding and Xen dom0 that has to
> all kinds of special one off hardware manipulation because Xen is too
> lazy too. 

Well the reason is the obvious one - Linux has a pile of drivers, and
attempting to duplicate them, or even port them into a completely
different environment - is a huge amount of pointless work.

>  Xen is already 300,000 lines of code so it's not like it is
> fully comprehensible/maintainable by a single person anyway.

Well, more like 200,000 for all the common code and arch/x86 (ia64 adds
another 30k lines or so).  By contrast, in Linux just kernel/ and
arch/x86/ is about 360,000 lines, and that doesn't include any drivers; 
drivers/ contains a further 5.8 million lines of code (~2 million in
scsi, net and block).

I don't see why it needs to be maintainable by a single person, though
there are probably only ~10 people who'd be classed as core developers. 
But while Xen and core Linux are about the same order of magnitude,
there's no way trying to import Linux drivers into Xen is even remotely
sustainable.

    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/