On Tue, Nov 25 2025, Peter Maydell <[email protected]> wrote: > On Tue, 25 Nov 2025 at 16:09, Cornelia Huck <[email protected]> wrote: >> >> On Mon, Nov 24 2025, Peter Maydell <[email protected]> wrote: >> >> > On Wed, 19 Nov 2025 at 13:44, Cornelia Huck <[email protected]> wrote: >> >> >> >> This requires a bit of care, since we still have to handle the EL >> >> specific part (DCZID_EL0.DZP). Callers can set/access dcz_blocksize >> >> via a wrapper working on DCZID_EL.BS. >> >> >> >> KVM currently does not support DCZID_EL0 via ONE_REG, and actually >> >> does not need to work with it, so provide a dummy value for now. >> > >> > That seems like an odd (unintended?) omission -- is it worth >> > adding? (We would need to handle older kernels that don't >> > expose it anyway, of course.) >> >> I'm not sure whether there's actually a usecase for KVM exposing this to >> the VMM - AFAICS, KVM doesn't do anything special for DC ZVA and >> friends, and doesn't tweak HCR_EL2.TDZ which would change behaviour. > > I guess the only one I can think of is to correctly fail > migration from a source CPU with a DCZID_EL0.BS that doesn't > match the one on the destination CPU. (We can't lie to the > guest about the blocksize as part of "tell the guest it has > a different CPU type from the actual host" unless we want to > trap and emulate all the DC ZVA etc insns...)
Agreed. Might actually be best to assert that kvm code is not doing anything with the reg, rather than providing a dummy value. I'll respin.
