On Fri, Feb 22, 2013 at 12:03:49PM +1100, Alexey Kardashevskiy wrote: > On 22/02/13 09:52, David Gibson wrote: > >On Tue, Feb 19, 2013 at 06:43:35PM +1100, Alexey Kardashevskiy wrote: [snip] > >You've implemented the multitce hypercalls in qemu, but because of the > >kvm capability check, you'll never advertise them in full emu. > >Instead you should always advertise them as available, and the kvm > >capability will just be a question of whether they go fast (through > >kvm) or slow (through qemu). > > So we do not need the KVM_CAP_PPC_MULTITCE capability at all as we > are not going to support real mode without multi-tce support in the > host kernel, is that correct?
Um.. is CAP_PPC_MULTITCE covering the version of the hypercalls for
emulated devices, for vfio devices or both. For emulated devices I
don't think we strictly need itm because we can fall back to qemu
fine. It might still be an idea to have the capability, so qemu or
the user know in advance if things are going to be slow or fast. For
now I think it's simplest for qemu to just do the fallback, but it's
possible we might want to advertise different things to the guest
based on whether they'll be fast or not.
For vfio.. there I don't think we need a capability, since multitce
hypercall support should be there from day one.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
