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
