linux-kernel - Re: hardwired VMI crap

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:	Thu, 8 Mar 2007 16:29:07 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Zachary Amsden <zach@...are.com>, Ingo Molnar <mingo@...e.hu>,
	tglx@...utronix.de, john stultz <johnstul@...ibm.com>,
	akpm@...ux-foundation.org, LKML <linux-kernel@...r.kernel.org>,
	Pratap Subrahmanyam <pratap@...are.com>,
	Rusty Russell <rusty@...tcorp.com.au>, Andi Kleen <ak@...e.de>,
	Daniel Hecht <dhecht@...are.com>,
	Daniel Arai <arai@...are.com>,
	Chris Wright <chrisw@...s-sol.org>,
	Virtualization Mailing List <virtualization@...ts.osdl.org>
Subject: Re: hardwired VMI crap

[ I don't really want to be involved too much in this particular 
  discussion, but I'll pipe up quickly anyway.. ]

On Thu, 8 Mar 2007, Jeremy Fitzhardinge wrote:

> Zachary Amsden wrote:
> > For APICs, we have two operations - APICRead and APICWrite.  It is
> > nice and clean, and plugs in very easily to the APIC accessors
> > available in Linux.
> >
> > Is this not clean?
> 
> Sure, that's clean, From that perspective the apic is a bunch of
> registers backed by a state machine or something.

I think you could do much worse than just decide to pick the IO-APIC/lapic 
as your "virtual interrupt controller model". So I do *not* think that 
APICRead/APICWrite are in any way horrible interfaces for a virtual 
interrupt controller. In many ways, you then have a tested and known 
interface to work with.

Of course, there are bound to be better interfaces that map more naturally 
to what people actually want to *do* ("[un]mask interrupt pin X", 
"acknowledge interrupt pin X" etc), but quite often the cost of an 
interface is *designing* it, so I don't think it's wrong per se to just 
avoid that cost entirely, and just say "we make our interface look like a 
known hardware interface". And then IOAPIC/lapic is the obvious choice.

So Ingo, I think you've been a bit unfair. I agree that it would be 
ugly to also try to emulate timers with that "fake local apic" setup, but 
even that ugliness is probably not horrid, especially if you want to have 
some kind of stable interface for an ABI.

Of course the whole "stable ABI" is fairly moot. The kernel clearly won't 
use the ABI, but a source-level API - and part of that is *exactly* that 
an ABI is by design always very inflexible and has to be backwards 
compatible. Make the API more high-level, and then the VMI "paravirt_ops" 
stuff can translate that higher-level API into its own low-level ABI any 
way it wants to.

I do agree that for timers, the lapic model is probably ugly enough that 
an ABI might be better off with somethign cleaner than just seeing timers 
too as part of the interrupt controller, but I doubt it really is  that 
big a deal. And I really think Ingo has made a bigger deal out of this 
than necessary, although clearly CONFIG_NO_HZ will require that the 
paravirt_ops will work on that level and will be able to translate it to 
whatever VMI interfaces there are.

		Linus
-
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/