[PATCH V2 5/5] cpu: Introduce getHost support for ARM CPU driver

[Zhenyu Zheng]

Ping for reviews

On Fri, Apr 10, 2020 at 5:55 PM Andrea Bolognani <abologna at redhat.com>
wrote:

> On Thu, 2020-04-09 at 13:03 +0200, Jiri Denemark wrote:
> > On Thu, Apr 02, 2020 at 17:03:59 +0800, Zhenyu Zheng wrote:
> > > +static int
> > > +armCpuDataFromRegs(virCPUarmData *data)
> > > +{
> > > +    /* Generate human readable flag list according to the order of */
> > > +    /* AT_HWCAP bit map */
> > > +    const char *flag_list[MAX_CPU_FLAGS] = {
> > > +        "fp", "asimd", "evtstrm", "aes", "pmull", "sha1", "sha2",
> > > +        "crc32", "atomics", "fphp", "asimdhp", "cpuid", "asimdrdm",
> > > +        "jscvt", "fcma", "lrcpc", "dcpop", "sha3", "sm3", "sm4",
> > > +        "asimddp", "sha512", "sve", "asimdfhm", "dit", "uscat",
> > > +        "ilrcpc", "flagm", "ssbs", "sb", "paca", "pacg"};
> >
> > I would expect these to be defined in src/cpu_map/arm_features.xml,
> > although I'm not sure how well the new features would play with the
> > existing ones... What do you think, Andrea?
>
> You tell me :)
>
> As you know, the main thing that sets x86 and ARM apart in this area
> is that on x86 you can basically mix and match CPU features at your
> heart's content, but on ARM this is not (yet) possible: the only
> features that you can really control are the SVE-related ones.
>
> I assume that, at some point further down the line, it will be
> possible to control ARM CPU features with a similar level of
> granularity as it's currently possible on x86, and at that point
> something like
>
>   <cpu>
>     <feature name='asimddp' policy='require'/>
>     <feature name='dcpop' policy='disable'/>
>   </cpu>
>
> will be possible, but that's certainly not the case now, and
> attempting to do so for non-SVE features will result in QEMU refusing
> to start.
>
> With that in mind, I don't think it's a problem to include these
> features in cpu_map upfront and report them in the context of the
> host CPU: any attempt to use them in guest CPU context will be
> blocked by QEMU anyway.
>
> Perhaps we could go one step further and fail validation in libvirt
> until such a time comes when QEMU is able to accept them? That would
> make for a more pleasant user experience, I think.
>
> Do you foresee any potential issues caused by this approach? As I
> said it seems to me like it would be fine, but you're the expert when
> it comes to the CPU drivers :)
>
> --
> Andrea Bolognani / Red Hat / Virtualization
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200417/8c375609/attachment-0001.htm>