https://bugs.kde.org/show_bug.cgi?id=414268
--- Comment #12 from Mark Wielaard <m...@klomp.org> --- (In reply to ahashmi from comment #11) > > Since programs can also check features through the attribute/feature > > registers, do we also need to filter those when inspected by the guest code? > Hmm...I don't see why we should. We aim to faithfully support features > detected, so if guest code reads those it should expect Valgrind to support > it. If Valgrind doesn't, it means we haven't yet implemented support for > that feature. (If I understand your question correctly.) So the question is not about this particular patch. But how we signal to the guest process which features valgrind/VEX supports itself. If the guest code checks the auxv HW_CAPS we are good because we filter out any features not implemented. But if the guest code checks attribute/feature registers it might get the attributes/features supported by the host. But if valgrind/VEX doesn't support those and the guest tries to use them it will get a SIGILL instead of trying to use fallback code. So it seems to me we also need a way to filter the attribute/feature registers to only advertise those armv8 instructions we actually implement. That is what other arches do too (see for example the dirtyhelper_CPUID in guest_x86_helpers.c or the s390x_dirtyhelper_vec_op). IMHO we should only pass through any bits set in these registers if we actually have implemented them (and preemptively zero out any future reserved ones). -- You are receiving this mail because: You are watching all bug changes.
