On Sun, Apr 21, 2013 at 03:51:16PM +0300, Gleb Natapov wrote:
> > Not nice?! It is a very nasty hack - that's what it is. :-)
> >
> Agree, but not nastier than expecting ->function to have special value :)
Probably of the same nastiness level :-)
> > Frankly speaking, I'd rather prefer adding a new ioctl. Since old
> > userspace won't support the new features, then we just as well can
> > simply add the new ioctl.
> >
> > In all the cases we need to touch userspace - be it to OR in the flags
> > into ->nent or to implement the new ioctl. So why not do it in a clean
> > manner from the get-go?
> >
> Agree here too.
Btw, in thinking about this more, I'm kinda sceptical we want to use the
CPUID layout for this new KVM_GET_EMULATED_* ioctl. And the reason why
I'm sceptical is that not every instruction is behind a CPUID capability
bit and if we want to tell userspace that we do emulate any insn, even
one for which there's no CPUID bit, we're going to have to either
simulate a kvm-specific CPUID leaf or, maybe even better, come up with
our own format for emulated capabilities. Maybe a bit vector with set
bits for the respective capability, or something more nifty.
In any case, it doesn't really need to be CPUID-like, IMHO.
Hmmm...
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
