All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Yoder Stuart-B08248 <B08248@freescale.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Wood Scott-B07421 <B07421@freescale.com>,
	Bhushan Bharat-R65777 <R65777@freescale.com>,
	Sethi Varun-B16395 <B16395@freescale.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Antonios Motakis <a.motakis@virtualopensystems.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: RFC: vfio interface for platform devices
Date: Wed, 03 Jul 2013 18:51:50 +0000	[thread overview]
Message-ID: <1372877510.8183.141@snotra> (raw)
In-Reply-To: <9001E680-3DF3-4B9A-97B9-D4B3DEFAB97C@suse.de> (from agraf@suse.de on Tue Jul  2 20:07:53 2013)

On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
> 
> On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
> 
> > 8.  Open Issues
> >
> >   -how to handle cases where VFIO is requested to handle
> >    a device where the valid, mappable range for a region
> >    is less than a page size.   See example above where an
> >    advertised region in the DMA node is 4 bytes.  If exposed
> >    to a guest VM, the guest has to be able to map a full page
> >    of I/O space which opens a potential security issue.
> 
> The way we solved this for legacy PCI device assignment was by going  
> through QEMU for emulation and falling back to legacy read/write  
> IIRC. We could probably do the same here. IIRC there was a way for a  
> normal Linux mmap'ed device region to trap individual accesses too,  
> so we could just use that one too.
> 
> The slow path emulation would then happen magically in QEMU, since  
> MMIO writes will get reinjected into the normal QEMU MMIO handling  
> path which will just issue a read/write on the mmap'ed region if it's  
> not declared as emulated.

I agree that's what should happen by default, but there should be a way  
for root to tell vfio that a device is allowed to overmap, in order to  
get the performance benefit of direct access in cases where root knows  
(or explicitly doesn't care) that it is safe.

-Scott

WARNING: multiple messages have this Message-ID (diff)
From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: Yoder Stuart-B08248 <B08248@freescale.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Wood Scott-B07421 <B07421@freescale.com>,
	Bhushan Bharat-R65777 <R65777@freescale.com>,
	Sethi Varun-B16395 <B16395@freescale.com>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Antonios Motakis <a.motakis@virtualopensystems.com>,
	"kvm@vger.kernel.org list" <kvm@vger.kernel.org>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: RFC: vfio interface for platform devices
Date: Wed, 3 Jul 2013 13:51:50 -0500	[thread overview]
Message-ID: <1372877510.8183.141@snotra> (raw)
In-Reply-To: <9001E680-3DF3-4B9A-97B9-D4B3DEFAB97C@suse.de> (from agraf@suse.de on Tue Jul  2 20:07:53 2013)

On 07/02/2013 08:07:53 PM, Alexander Graf wrote:
> 
> On 03.07.2013, at 01:25, Yoder Stuart-B08248 wrote:
> 
> > 8.  Open Issues
> >
> >   -how to handle cases where VFIO is requested to handle
> >    a device where the valid, mappable range for a region
> >    is less than a page size.   See example above where an
> >    advertised region in the DMA node is 4 bytes.  If exposed
> >    to a guest VM, the guest has to be able to map a full page
> >    of I/O space which opens a potential security issue.
> 
> The way we solved this for legacy PCI device assignment was by going  
> through QEMU for emulation and falling back to legacy read/write  
> IIRC. We could probably do the same here. IIRC there was a way for a  
> normal Linux mmap'ed device region to trap individual accesses too,  
> so we could just use that one too.
> 
> The slow path emulation would then happen magically in QEMU, since  
> MMIO writes will get reinjected into the normal QEMU MMIO handling  
> path which will just issue a read/write on the mmap'ed region if it's  
> not declared as emulated.

I agree that's what should happen by default, but there should be a way  
for root to tell vfio that a device is allowed to overmap, in order to  
get the performance benefit of direct access in cases where root knows  
(or explicitly doesn't care) that it is safe.

-Scott

  parent reply	other threads:[~2013-07-03 18:51 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-02 23:25 RFC: vfio interface for platform devices Yoder Stuart-B08248
2013-07-02 23:25 ` Yoder Stuart-B08248
2013-07-03  1:07 ` Alexander Graf
2013-07-03  1:07 ` Alexander Graf
2013-07-03  1:07   ` Alexander Graf
2013-07-03 18:51   ` Scott Wood
2013-07-03 18:51   ` Scott Wood [this message]
2013-07-03 18:51     ` Scott Wood
2013-07-03 19:08     ` Yoder Stuart-B08248
2013-07-03 19:08       ` Yoder Stuart-B08248
2013-07-03  3:07 ` Alex Williamson
2013-07-03  3:07   ` Alex Williamson
2013-07-03 10:44   ` Antonios Motakis
2013-07-03 10:44     ` Antonios Motakis
2013-07-03 19:23     ` Yoder Stuart-B08248
2013-07-03 19:23     ` Yoder Stuart-B08248
2013-07-03 19:23       ` Yoder Stuart-B08248
2013-07-03 10:44   ` Antonios Motakis
2013-07-03 17:20   ` Yoder Stuart-B08248
2013-07-03 17:20     ` Yoder Stuart-B08248
2013-07-03 21:40 ` RFC: vfio interface for platform devices (v2) Yoder Stuart-B08248
2013-07-03 21:40   ` Yoder Stuart-B08248
2013-07-03 22:53   ` Alex Williamson
2013-07-03 22:53   ` Alex Williamson
2013-07-03 22:53     ` Alex Williamson
2013-07-03 23:06     ` Scott Wood
2013-07-03 23:06     ` Scott Wood
2013-07-03 23:06       ` Scott Wood
2013-07-16 21:57     ` Yoder Stuart-B08248
2013-07-16 21:57     ` Yoder Stuart-B08248
2013-07-16 21:57       ` Yoder Stuart-B08248
2013-07-04 14:44   ` Mario Smarduch
2013-07-04 14:44   ` Mario Smarduch
2013-07-04 14:44     ` Mario Smarduch
2013-07-04 14:47     ` Alexander Graf
2013-07-04 14:47     ` Alexander Graf
2013-07-04 14:47       ` Alexander Graf
2013-07-16 15:25     ` Yoder Stuart-B08248
2013-07-03 22:31 ` RFC: vfio interface for platform devices Scott Wood
2013-07-03 22:31 ` Scott Wood
2013-07-03 22:31   ` Scott Wood
2013-07-16 21:51   ` Yoder Stuart-B08248
2013-07-16 21:51   ` Yoder Stuart-B08248
2013-07-16 22:01     ` Scott Wood
2013-07-16 22:01       ` Scott Wood
2013-07-16 22:41       ` Yoder Stuart-B08248
2013-07-16 22:50         ` Scott Wood
2013-07-16 22:50         ` Scott Wood
2013-07-16 22:50           ` Scott Wood
2013-07-16 22:01     ` Scott Wood
  -- strict thread matches above, loose matches on Subject: below --
2013-07-02 23:25 Yoder Stuart-B08248

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=1372877510.8183.141@snotra \
    --to=scottwood@freescale.com \
    --cc=B07421@freescale.com \
    --cc=B08248@freescale.com \
    --cc=B16395@freescale.com \
    --cc=R65777@freescale.com \
    --cc=a.motakis@virtualopensystems.com \
    --cc=agraf@suse.de \
    --cc=alex.williamson@redhat.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=virtualization@lists.linux-foundation.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.