attaching cpu via lapic

[Cherry G. Mathew <cherry%zyx.in@localhost>]

Hello,

I'm trying to improve the semantics around x86 lapic vs. cpu, with a
view to wedging in the concept of "vcpu"s.

TLDR: please review this patch:
http://ftp.netbsd.org/pub/NetBSD/misc/cherry/tmp/attach-cpu-with-lapic.diff

Essentially, the idea is that when the kernel runs under a hypervisor
which it can detect, and this hypervisory exports a "virtual cpu" to the
guest OS, this can be understood in the context of NetBSD's cpu device.

The current attachment is as follows:

'attach cpu at cpubus'

which is then constrained via:

'cpu* at mainbus'

similarly in the virtualised case:
'attach vcpu at xendevbus'

and,

'vcpu* at hypervisor'

I've thought of a couple of schemes, but my current thought is as
follows:

attach cpu at cpubus with lapic
attach cpu at xendevbus with xvcpu

cpu* at mainbus #(via x86/(mpacpi.c|mpbios.c) as usual)
cpu* at hypervisor #(via xen/hypervisor.c as usual)

The idea is that the attachment is mediated by the lapic/xvcpu
respectively which can then decide how to go forward (vcpus on xen pvhvm
don't need to fully initialise the underlying cpu, for eg: whereas
physical cpus on xen dom0 cannot fully initialise, since xen disallows
full access to the corresponding lapic).

The situation for XEN is as follows:

PV domU - only vcpu
HVM domU - only cpu
PVHVM domU - cpu:vcpu -> 1:1
PVH dom0 - cpu:vcpu -> 1:1 (IIUC)
PV dom0 - cpu:vcpu -> vcpu can be fewer than cpu

Thus I'm trying to dissect the attach path of x86 cpu in such a way that
it makes the least amount of 'platform' assumptions. The above patch is
a first cut at taking out 'lapic' related assumptions in the native cpu
attach path.

Comments ?
-- 
~cherry