On Tue, Jan 12, 2021 at 10:16:30AM -0300, Daniel Henrique Barboza wrote: > > > On 1/6/21 5:59 AM, Bharata B Rao wrote: > > If KVM_CAP_RPT_INVALIDATE KVM capability is enabled, then > > > > - indicate the availability of H_RPT_INVALIDATE hcall to the guest via > > ibm,hypertas-functions property. > > - Enable the hcall > > > > Both the above are done only if the new sPAPR machine capability > > cap-rpt-invalidate is set. > > > > Note: The KVM implementation of the hcall has been posted for upstream > > review here: > > https://lore.kernel.org/linuxppc-dev/20210105090557.2150104-1-bhar...@linux.ibm.com/T/#t > > > > Update to linux-headers/linux/kvm.h here is temporary, will be > > done via header updates once the kernel change is accepted upstream. > > > > Signed-off-by: Bharata B Rao <bhar...@linux.ibm.com> > > --- > > Code LGTM. > > Reviewed-by: Daniel Henrique Barboza <danielhb...@gmail.com> > > > A few questions about the logic: > > - does it work only on Power 9 like you mentioned in the error message > down below? If it's supported on Power 10 as well then we would want the > error message to read "H_RPT_INVALIDATE only supported on POWER9 and newer" > to contemplate it.
Making it conditional to Power 9 was an oversight, will remove in the next iteration. > > - Does it make sense to expose "rpt-invalidate" to Libvirt? I see that the > capability is turned off by default, which may indicate that even if kernel > and QEMU support is present the user might want to not enable it. Is there > some sort of drawback/compromise when activating this cap? I have added this to take care of migration compatibility between source and target when hcall is present in target and not present in source or vice versa. I wonder if there is any other preferred method than introducing a new machine capability like cap-rpt-invalidate. Regards, Bharata.
