[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06)
From: |
Christoffer Dall |
Subject: |
Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06) |
Date: |
Thu, 8 Aug 2013 12:29:07 -0700 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Aug 08, 2013 at 08:05:11PM +0100, Peter Maydell wrote:
> On 8 August 2013 19:39, Christoffer Dall <address@hidden> wrote:
> > FWIW, from the kernel point of view I'd much prefer to return "this is
> > the type of VCPU that I prefer to emulate" to user space on this current
> > host than having QEMU come up with its own suggestion for CPU and asking
> > the kernel for it. The reason is that it gives us slightly more freedom
> > in how we choose to support a given host SoC in that we can say that we
> > at least support core A on core B, so if user space can deal with a
> > virtual core A, we should be good.
>
> Hmm, I'm not sure how useful a "query support" kind of API would
> be to QEMU. QEMU is basically going to have two use cases:
> (1) "I want an A15" [ie -cpu cortex-a15]
> (2) "give me whatever you have and I'll cope" [ie -cpu host]
>
> so my thought was that we could just have the kernel support
> init.target = KVM_ARM_TARGET_HOST;
> memset(init.features, 0, sizeof(init.features));
> ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
>
> (in the same way we currently ask for KVM_ARM_TARGET_CORTEX_A15).
>
> I guess we could have a "return preferred target value"
> VM ioctl, but it seems a bit pointless given that the
> only thing userspace is going to do with the return
> value is immediately feed it back to the kernel...
>
My thinking was that the result of cpu = KVM_ARM_TARGET_HOST would be
the same as x = kvm_get_target_host(), cpu = x, but at the same time
letting QEMU know what it's dealing with. Perhaps QEMU doesn't need
this for emulation, but isn't it useful for
save/restore/migration/debugging scenarios?
So, if you just use the KVM_ARM_TARGET_HOST value, do you expect the
kernel to just set the base address of the GIC interface, or?
-Christoffer
- [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Peter Maydell, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Andreas Färber, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Peter Maydell, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Christoffer Dall, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Peter Maydell, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06),
Christoffer Dall <=
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Peter Maydell, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Christoffer Dall, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Peter Maydell, 2013/08/08
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Eduardo Habkost, 2013/08/09
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Gleb Natapov, 2013/08/25
- Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Gleb Natapov, 2013/08/25
Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Gleb Natapov, 2013/08/25
Re: [Qemu-devel] -cpu host (was Re: KVM call minutes for 2013-08-06), Peter Maydell, 2013/08/09