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

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