On Wed, Dec 09, 2020 at 03:15:42PM +1100, Paul Mackerras wrote: > On Mon, Oct 19, 2020 at 04:56:41PM +0530, Bharata B Rao wrote: > > Implements H_RPT_INVALIDATE hcall and supports only nested case > > currently. > > > > A KVM capability KVM_CAP_RPT_INVALIDATE is added to indicate the > > support for this hcall. > > I have a couple of questions about this patch: > > 1. Is this something that is useful today, or is it something that may > become useful in the future depending on future product plans? In > other words, what advantage is there to forcing L2 guests to use this > hcall instead of doing tlbie themselves? H_RPT_INVALIDATE will replace the use of the existing H_TLB_INVALIDATE for nested partition scoped invalidations. Implementations that want to off-load invalidations to the host (when GTSE=0) would have to bother about only one hcall (H_RPT_INVALIDATE) > > 2. Why does it need to be added to the default-enabled hcall list? > > There is a concern that if this is enabled by default we could get the > situation where a guest using it gets migrated to a host that doesn't > support it, which would be bad. That is the reason that all new > things like this are disabled by default and only enabled by userspace > (i.e. QEMU) in situations where we can enforce that it is available on > all hosts to which the VM might be migrated. As you suggested privately, I am thinking of falling back to H_TLB_INVALIDATE in case where this new hcall fails due to not being present. That should address the migration case that you mention above. With that and leaving the new hcall enabled by default is good okay? Regards, Bharata.
