On 14.08.2013, at 19:26, Christoffer Dall wrote: > On Wed, Aug 14, 2013 at 11:30:46AM +0200, Alexander Graf wrote: >> >> On 14.08.2013, at 11:23, Peter Maydell wrote: >> >>> On 14 August 2013 10:11, Alexander Graf <agraf@xxxxxxx> wrote: >>>> You're right, the main difference is that KVM doesn't have any >>>> idea what a "host" style CPU is. It only knows how to report to QEMU >>>> what the current host CPU would be, so that anything from VCPU_INIT >>>> onwards is 100% identical regardless of whether the user said >>>> -cpu host or -cpu xxx. >>>> >>>> I'm still puzzled on how this will work with BIG.little btw. >>> >>> The rough idea is that for BIG.little the kernel must trap the >>> ID registers at least (so that the vcpu seems consistent to the >>> guest whether it's running on the big or the little core). For >>> "-cpu host" the guest would see whatever is the most low-overhead >>> for the kernel to provide (ie assuming the big and little CPUs >>> are roughly-similar you could make -cpu host provide something >>> that looks to the guest like the big CPU and don't have to trap >>> quite as much as you would for providing a vcpu that wasn't the >>> same as either the big or little one). >> >> So -cpu host in this case wouldn't actually expose the host CPU 1:1, but instead a cortex-a15 even when it's run on an a7 BIG.little core. I see. >> > Yes, from the discussion we've had the whole picture just becomes to > blurry when you start presenting multiple different CPUs to the guest > and there's really no need to that I'm aware of. > > In fact the -cpu host case fits quite nicely with this state of mind; > the kernel is free to decide based on the specific hardware and config > on which it's running how to handle VMs on BL. So why not have a vm ioctl to fetch the "best match" vcpu type? I don't like the idea of adding any awareness of a "host" type to the normal vcpu creation process. Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
