qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [kvmarm] [PATCH] target-arm: kvm: use KVM_SET_SREGS to


From: Rusty Russell
Subject: Re: [Qemu-devel] [kvmarm] [PATCH] target-arm: kvm: use KVM_SET_SREGS to set target to Cortex A15
Date: Mon, 16 Jul 2012 16:49:43 +0930
User-agent: Notmuch/0.12 (http://notmuchmail.org) Emacs/23.3.1 (i686-pc-linux-gnu)

On Fri, 13 Jul 2012 12:06:26 +0200, Alexander Graf <address@hidden> wrote:
> > struct kvm_sregs {
> > +    __u32 target;
> > +    __u32 num_features;
> > +    __u32 features[14];
> > };
> 
> Are you sure you want to use sregs? We did the mistake of reusing it
> on ppc, but that doesn't mean you need to repeat the same one :)
> 
> Basically sregs are an x86 specific struct for its segment register
> information. I'm quite sure that this is not what your use of them is
> here.

Since each arch is given a hook already, I just abused it.  I'll change
this to a fresh KVM_ARM_SET_TARGET ioctl.  

> 3) ENABLE_CAP
> 
> If you only need to enable a feature and care about backwards
> compatibility of the API (which you don't yet), this is a good one. it
> basically allows you to enable new features in newer kernel versions
> which would otherwise break compatibility. You can also pass arbitrary
> data to ENABLE_CAP to pass in additional information.

Hmm, it's not quite a clean fit: this bitmap is for guest features, not
kvm ones.  Which ones you can enable depends on the target CPU, at least
in theory.

eg. FP/NEON support and debug register support are (in theory) optional
features for an implementation.  There may be more in future, I guess.

And you really want to initialize this all at the same time; eg. the cpu
identification registers need to be initialized depending on the
presence of various features.  It's also possible that various features
may be related, so you can't turn a single one off at a time.

Currently, it's a bit theoretical, since we don't have any guest
features, but it was suggested that we'll want them in future.

Cheers,
Rusty.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]