All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Ilya Lesokhin <ilyal@mellanox.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	Adi Menachem <adim@mellanox.com>
Subject: Re: Shouldn't VFIO virtualize the ATS capability?
Date: Wed, 9 Nov 2016 08:53:26 -0700	[thread overview]
Message-ID: <20161109085326.62b47d2f@t450s.home> (raw)
In-Reply-To: <VI1PR0502MB2957CCD1E8EE93A3BC6CE178D4B90@VI1PR0502MB2957.eurprd05.prod.outlook.com>

On Wed, 9 Nov 2016 15:25:16 +0000
Ilya Lesokhin <ilyal@mellanox.com> wrote:

> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Wednesday, November 09, 2016 5:08 PM
> > To: Ilya Lesokhin <ilyal@mellanox.com>
> > Cc: linux-pci@vger.kernel.org; kvm@vger.kernel.org; bhelgaas@google.com;
> > Adi Menachem <adim@mellanox.com>
> > Subject: Re: Shouldn't VFIO virtualize the ATS capability?
> > 
> > On Wed, 9 Nov 2016 14:49:02 +0000
> > Ilya Lesokhin <ilyal@mellanox.com> wrote:
> >   
> > > I would virtualize the "ATS Control Register".  
> > 
> > And do what?  
> I think it should be read only.

That would violate the spec, in which case it shouldn't be virtualized,
the capability should be hidden.
 
> > > Regarding poor behavior, I couldn't really find what happens when ATS is  
> > misconfigured, but I would assume it can cause problems.  
> > > The scenarios I'm concerned about are:
> > > 	1. The guest enables translation caching, while the hypervisor thinks  
> > there are disabled -> Hypervisor won't issue invalidations.
> > 
> > Aren't invalidations issued by the iommu, why does the hypervisor need to
> > participate?  How would a software entity induce an invalidation?  
> That's what one might expect from a sane design, but
> http://lxr.free-electrons.com/source/drivers/iommu/intel-iommu.c?v=4.8#L1549
> seems to imply otherwise :(
> >   
> > > 	2. Smallest Translation Unit misconfiguration. Not sure if it will cause  
> > invalid access or only poor caching behavior.  
> > >
> > > Thanks,
> > > Ilya
> > >  
> > > > -----Original Message-----
> > > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > > Sent: Sunday, November 06, 2016 7:09 PM
> > > > To: Ilya Lesokhin <ilyal@mellanox.com>
> > > > Cc: linux-pci@vger.kernel.org; kvm@vger.kernel.org;
> > > > bhelgaas@google.com
> > > > Subject: Re: Shouldn't VFIO virtualize the ATS capability?
> > > >
> > > > On Sun, 6 Nov 2016 11:13:09 +0000
> > > > Ilya Lesokhin <ilyal@mellanox.com> wrote:
> > > >  
> > > > > Hi
> > > > > I've noticed that VFIO doesn't virtualize the ATS capability.
> > > > > It seems to me that translation caching and Smallest Translation
> > > > > Unit is  
> > > > something you would want to control on the host. Am I wrong?
> > > >
> > > > What about those fields would we virtualize?  Why does the host need
> > > > to be an intermediary?  Can the user induce poor behavior with
> > > > direct access to them?  Thanks,
> > > >
> > > > Alex  
> 


  reply	other threads:[~2016-11-09 15:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-06 11:13 Shouldn't VFIO virtualize the ATS capability? Ilya Lesokhin
2016-11-06 11:13 ` Ilya Lesokhin
2016-11-06 17:08 ` Alex Williamson
2016-11-09 14:49   ` Ilya Lesokhin
2016-11-09 14:49     ` Ilya Lesokhin
2016-11-09 15:07     ` Alex Williamson
2016-11-09 15:25       ` Ilya Lesokhin
2016-11-09 15:25         ` Ilya Lesokhin
2016-11-09 15:53         ` Alex Williamson [this message]
2016-11-09 15:55           ` Ilya Lesokhin
2016-11-09 15:55             ` Ilya Lesokhin
2016-12-01 23:22             ` Alex Williamson
2016-12-02  7:45               ` Ilya Lesokhin
2016-12-02  7:45                 ` Ilya Lesokhin
2016-12-02 15:58                 ` Alex Williamson
2016-12-05  7:07                   ` Ilya Lesokhin
2016-12-05  7:07                     ` Ilya Lesokhin

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=20161109085326.62b47d2f@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=adim@mellanox.com \
    --cc=bhelgaas@google.com \
    --cc=ilyal@mellanox.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-pci@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.