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

[Andrea Bolognani]

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