[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: attaching cpu via lapic
On 21 August 2017 1:54:12 am IST, John Nemeth <jnemeth%cue.bc.ca@localhost> wrote:
>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:
>} Essentially, the idea is that when the kernel runs under a hypervisor
>} which it can detect, and this hypervisory exports a "virtual cpu" to
>} guest OS, this can be understood in the context of NetBSD's cpu
>} 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
>} don't need to fully initialise the underlying cpu, for eg: whereas
>} physical cpus on xen dom0 cannot fully initialise, since xen
>} 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.
In this case, the CPU is actually exported to the domU as a x86 cpu as well as vcpu. This has nothing to do with baremetal cpu which is invisible to HVM domain guests. So you can have upto the currently supported max of these CPUs regardless of the baremetal number.
Sent via phone. Sorry it's short.
Main Index |
Thread Index |