Re: attaching cpu via lapic

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Aug 19,  1:31am, "Cherry G. Mathew" wrote:
} 
} 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

     Why is this 1:1?  This seems to be a serious limitation that
will reduce the number of VMs that a given box can handle.

} 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.
} 
}-- End of excerpt from "Cherry G. Mathew"