mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: David Hildenbrand <david@redhat.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lpivarc@redhat.com" <lpivarc@redhat.com>,
	"Liu, Jingqi" <jingqi.liu@intel.com>,
	"Lu, Baolu" <baolu.lu@intel.com>
Subject: Re: [PATCH] vfio/type1: Unpin zero pages
Date: Wed, 7 Sep 2022 16:55:50 -0300	[thread overview]
Message-ID: <Yxj3Ri8pfqM1SxWe@ziepe.ca> (raw)
In-Reply-To: <20220907125627.0579e592.alex.williamson@redhat.com>

On Wed, Sep 07, 2022 at 12:56:27PM -0600, Alex Williamson wrote:

> I thought we'd already agreed that we were stuck with locked_vm for
> type1 and any compatibility mode of type1 due to this.  Native iommufd
> support can do the right thing since userspace will need to account for
> various new usage models anyway.

We did, that was for the iommufd situation (which will also hit the
same zeropage issue, sigh) - this discussion is about fixing a bug in
vfio and what many consider a bug in GUP.

My point is I'm still not convinced we can really consider these
limits as ABI because it opens a pandoras box of kernel limitations.

> I've raised the issue with David for the zero page accounting, but I
> don't know what the solution is.  libvirt automatically adds a 1GB
> fudge factor to the VM locked memory limits to account for things like
> ROM mappings, or at least the non-zeropage backed portion of those
> ROMs.  I think that most management tools have adopted similar, so the
> majority of users shouldn't notice.  However this won't cover all
> users, so we certainly risk breaking userspace if we introduce hard
> page accounting of zero pages.

It sounds like things will be fine. 1GB fudge is pretty big.

For things like this ABI compat is not about absolute compatability in
the face of any userspace, but a real-world compatibility "does
something that actually exists break?"

So I would be happier if we had an actual deployed thing that breaks..
I would be inclined to go with the simple fix and rely on the
fudge. If someone does come with an actual break then lets do one of
the work arounds.

Given the whole thing is obstensibly for security it is better to keep
it simple and sane then to poke it full of holes.

> module parameter defined limit.  We might also consider whether we
> could just ignore zero page mappings, maybe with a optional "strict"
> mode module option to generate an errno on such mappings.  Thanks,

Once GUP is fixed vfio won't see the zero pages anymore :( That really
limits the choices for a work around :(

Jason 

  parent reply	other threads:[~2022-09-07 19:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30  3:05 Alex Williamson
2022-08-30  5:34 ` Sean Christopherson
2022-08-30  7:59 ` David Hildenbrand
2022-08-30 15:11   ` Alex Williamson
2022-08-30 15:43     ` David Hildenbrand
2022-09-02  0:53       ` Jason Gunthorpe
2022-09-02  8:24 ` Tian, Kevin
2022-09-02  8:32   ` David Hildenbrand
2022-09-02  9:09     ` Tian, Kevin
2022-09-06 23:30     ` Jason Gunthorpe
2022-09-07  9:00       ` David Hildenbrand
2022-09-07 12:48         ` Jason Gunthorpe
2022-09-07 15:55           ` Alex Williamson
2022-09-07 16:40             ` Jason Gunthorpe
2022-09-07 18:56               ` Alex Williamson
2022-09-07 19:14                 ` David Hildenbrand
2022-09-07 19:55                 ` Jason Gunthorpe [this message]
2022-09-07 20:24                   ` Alex Williamson
2022-09-07 23:07                     ` Jason Gunthorpe
2022-09-08  1:10                       ` Alex Williamson

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=Yxj3Ri8pfqM1SxWe@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@intel.com \
    --cc=david@redhat.com \
    --cc=jingqi.liu@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpivarc@redhat.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

all inboxes | Powered by JetHome®