From: sathyanarayanan kuppuswamy <sathyanarayanan.kuppuswamy@linux.intel.com>
To: David Woodhouse <dwmw2@infradead.org>,
"Raj, Ashok" <ashok.raj@intel.com>
Cc: joro@8bytes.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Jacob Pan <jacob.jun.pan@linux.intel.com>
Subject: Re: [PATCH v1 1/1] iommu/vt-d: Enable PRI only if the device enables PASID.
Date: Thu, 7 Feb 2019 13:30:24 -0800 [thread overview]
Message-ID: <cdb6fb16-157e-059e-44ee-515fb4aca9af@linux.intel.com> (raw)
In-Reply-To: <9393b9b2c15564ee84b627a73fb34bd17ebe4a7f.camel@infradead.org>
On 2/7/19 1:15 PM, David Woodhouse wrote:
> On Thu, 2019-02-07 at 13:09 -0800, Raj, Ashok wrote:
>> You are right.. they are completely orthogonal. We just don't have
>> a way to handle the page-requests for request without PASID's.
>>
>> There are some of the vIOMMU work to pass the PRI to who owns
>> the device, and we can certainly relax it then. This is just to reflect
>> what support exists today. FWIW, even the native driver maybe be able
>> to resolve this if supported.
> As things stand, if a device makes a PRI request without a PASID, it'll
> get told that we didn't manage to bring the page in for it. Which is
> true.
>
> What's the actual problem being fixed by this patch?
Since the request is going to fail any way why go through the process of
enabling it ? Once the functionality (PRI without PASID) is supported,
then they can revert this patch. Just we are trying to expose whats
currently supported clearly.
> Yes, we're going
> to want to hook up a way to pass the PRI to the right place... but why
> add *another* thing that's just going to have to be fixed, by reverting
> this patch?
>
--
Sathyanarayanan Kuppuswamy
Linux kernel developer
prev parent reply other threads:[~2019-02-07 21:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 18:44 [PATCH v1 1/1] iommu/vt-d: Enable PRI only if the device enables PASID sathyanarayanan.kuppuswamy
2019-02-07 20:08 ` David Woodhouse
2019-02-07 21:09 ` Raj, Ashok
2019-02-07 21:15 ` David Woodhouse
2019-02-07 21:22 ` Raj, Ashok
2019-02-07 21:30 ` sathyanarayanan kuppuswamy [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=cdb6fb16-157e-059e-44ee-515fb4aca9af@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=joro@8bytes.org \
--cc=linux-kernel@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.