[ 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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxx
https://lists.osdl.org/mailman/listinfo/virtualization
