[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: attaching cpu via lapic
On Sat, Aug 19, 2017 at 01:31:09AM +0530, 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:
> 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'
> 'vcpu* at hypervisor'
> I've thought of a couple of schemes, but my current thought is as
> 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
Main Index |
Thread Index |