Re: [RFC PATCH v0 1/1] target/ppc: Support for H_RPT_INVALIDATE hcall

[Bharata B Rao <bharata@linux.ibm.com>]

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-bharata@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 <bharata@linux.ibm.com>
> > ---
> 
> Code LGTM.
> 
> Reviewed-by: Daniel Henrique Barboza <danielhb413@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.