Re: attaching cpu via lapic

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Aug 19, 2017 at 01:31:09AM +0530, Cherry G. Mathew wrote:
> 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).

I may be wrong (it's from memory and I didn't check the sources)
but I think Xen Dom0 support needs the physical CPUs, for proper
physical interrupt routing. The dom0 is doing the physical APIC configurations

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--