Ping for reviews On Fri, Apr 10, 2020 at 5:55 PM Andrea Bolognani <abolo...@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 > >