qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@linux.ibm.com>
To: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: paulus@ozlabs.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	david@gibson.dropbear.id.au
Subject: Re: [RFC PATCH v0 1/1] target/ppc: Support for H_RPT_INVALIDATE hcall
Date: Wed, 13 Jan 2021 20:22:06 +0530	[thread overview]
Message-ID: <20210113145206.GA2421313@in.ibm.com> (raw)
In-Reply-To: <2fbd70fa-17a0-2776-e4ae-a4b128713921@gmail.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.





  reply	other threads:[~2021-01-13 14:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  8:59 Bharata B Rao
2021-01-12 13:16 ` Daniel Henrique Barboza
2021-01-13 14:52   ` Bharata B Rao [this message]
2021-01-13 16:22 ` Greg Kurz
2021-01-15  8:31   ` Bharata B Rao
2021-01-15 17:30     ` Greg Kurz
2021-01-19  4:44       ` Bharata B Rao
2021-01-19  8:01         ` Greg Kurz
2021-01-18  3:08     ` David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210113145206.GA2421313@in.ibm.com \
    --to=bharata@linux.ibm.com \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=paulus@ozlabs.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --subject='Re: [RFC PATCH v0 1/1] target/ppc: Support for H_RPT_INVALIDATE hcall' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).