All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 04/13] KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE
Date: Wed, 23 Jan 2019 18:00:00 +0000	[thread overview]
Message-ID: <20190123180000.GP6360@ram.ibm.com> (raw)
In-Reply-To: <1548172784-27414-5-git-send-email-linuxram@us.ibm.com>

On Wed, Jan 23, 2019 at 10:48:20AM +1100, Paul Mackerras wrote:
> On Tue, Jan 22, 2019 at 07:59:35AM -0800, Ram Pai wrote:
> > From: Michael Anderson <andmike@linux.ibm.com>
> > 
> > The Nest_MMU needs to know the address of the Partition table (PT).
> > However the PT is in secure memory, and nestMMU cannot access secure
> > memory.  Hence hypevisor will continue to use a Partition table of
> > its own. It will have PATE entries for HV and for Normal virtual
> > machines. The same entries are also in the UV's PT.  The HV's PT
> > is programmed with the nest MMU.
> 
> This isn't a good patch description.  It's confusing because it
> doesn't start with the primary motivation of the patch - which is that
> when running under an ultravisor, the ultravisor controls the real
> partition table and has it in secure memory where the hypervisor can't
> access it, and therefore we (the HV) have to do a ucall whenever we
> want to update an entry.  Once you have explained that, then you can
> explain the secondary aspect of the patch, which is that the HV still
> keeps a copy of its view of the partition table in normal memory so
> that the nest MMU can access it.
> 
> > Suggested-by: Ryan Grimm <grimm@linux.vnet.ibm.com>
> > Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> > [device node name to ibm,ultravisor]
> > Signed-off-by: Michael Anderson <andmike@linux.ibm.com>
> > Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> 
> If Michael Anderson wrote the patch and sent it to you, and you sent
> it to the list, why is Maddy's signoff relevant?  Was the original
> version of the patch actually written by Maddy?

Yes. this patch description needs a good amount work.  A couple of
related patches; some by Michael and some by me and some bug fixes by Maddy,
were merged  leading to this signoff cocktail and incoherent
description.

This was my first attempt to bring a logical order to
our internal set of patches, which I agree has some more way to go. :(

Thanks,
RP

      parent reply	other threads:[~2019-01-23 18:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 15:59 [PATCH 04/13] KVM: PPC: Ultravisor: Use UV_WRITE_PATE ucall to register a PATE Ram Pai
2019-01-22 23:48 ` Paul Mackerras
2019-01-23 18:00 ` Ram Pai [this message]

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=20190123180000.GP6360@ram.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=kvm-ppc@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.