linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@ozlabs.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>,
	linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Nicholas Piggin <npiggin@gmail.com>
Subject: Re: [PATCH kernel] KVM: PPC: Avoid mapping compound pages to TCEs in real mode
Date: Mon, 3 Sep 2018 15:15:29 +1000	[thread overview]
Message-ID: <20180903051529.GA7848@fergus> (raw)
In-Reply-To: <20180903032844.GD2679@umbus.fritz.box>

On Mon, Sep 03, 2018 at 01:28:44PM +1000, David Gibson wrote:
> On Fri, Aug 31, 2018 at 04:08:50PM +1000, Alexey Kardashevskiy wrote:
> > At the moment the real mode handler of H_PUT_TCE calls iommu_tce_xchg_rm()
> > which in turn reads the old TCE and if it was a valid entry - marks
> > the physical page dirty if it was mapped for writing. Since it is
> > the real mode, realmode_pfn_to_page() is used instead of pfn_to_page()
> > to get the page struct. However SetPageDirty() itself reads the compound
> > page head and returns a virtual address for the head page struct and
> > setting dirty bit for that kills the system.
> > 
> > This moves dirty bit setting before updating the hardware table
> 
> Um.. but now you're setting DIRTY based on the *new* TCE's
> permissions, instead of the old TCE's permissions, which I don't think
> is correct.

He's setting dirty on the page which is about to be mapped if the new
TCE allows the page to be written by the device.  Given that the page
is pinned, I don't see any reason why the dirty setting has to be done
when the page is unmapped rather than when it is mapped.  Do you see a
reason?

Paul.

  reply	other threads:[~2018-09-03  5:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31  6:08 [PATCH kernel] KVM: PPC: Avoid mapping compound pages to TCEs in real mode Alexey Kardashevskiy
2018-09-03  3:28 ` David Gibson
2018-09-03  5:15   ` Paul Mackerras [this message]
2018-09-03  5:17     ` 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=20180903051529.GA7848@fergus \
    --to=paulus@ozlabs.org \
    --cc=aik@ozlabs.ru \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=npiggin@gmail.com \
    /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 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).