All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Xiantao" <xiantao.zhang@intel.com>
To: Jan Beulich <JBeulich@suse.com>,
	"Zhang, Yang Z" <yang.z.zhang@intel.com>
Cc: "wei.huang2@amd.com" <wei.huang2@amd.com>,
	"weiwang.dd@gmail.com" <weiwang.dd@gmail.com>,
	"Zhang, Xiantao" <xiantao.zhang@intel.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: iommu=dom0-passthrough behavior
Date: Wed, 14 Nov 2012 00:37:39 +0000	[thread overview]
Message-ID: <B6C2EB9186482D47BD0C5A9A4834564403371EA4@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <50A2755402000078000A837D@nat28.tlf.novell.com>



> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: Tuesday, November 13, 2012 11:29 PM
> To: Zhang, Xiantao; Zhang, Yang Z
> Cc: wei.huang2@amd.com; weiwang.dd@gmail.com; xen-devel
> Subject: RE: [Xen-devel] iommu=dom0-passthrough behavior
> 
> >>> On 13.11.12 at 16:02, "Zhang, Xiantao" <xiantao.zhang@intel.com>
> wrote:
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> > If software cannot see it, then how to use it? If there still have
> >> > an approach to detect it, then xen can do it too and setup the
> >> > context entry as passthrough.
> >>
> >> We see it the latest at the point the fault occurs. So there are
> >> multiple
> >> options:
> >> a) if the device is "real" as in having a valid config space despite
> >>     func 0 not advertising itself as multi-function, we have ways to
> >>     discover the device (at boot time)
> >
> > I think current Xen logic also covers multi-function devices case.
> > When Xen boots up, it will scan all functions of devices on each bus,
> > through reads their vendor ID.  If the vendor ID is valid, Xen deems
> > this BDF has a real device/function existed there
> 
> Not anymore - we're now honoring the multi-function flag in
> _scan_pci_devices() (as Linux always did in its bus scan logic); see c/s
> 22337:7afd8dd1d6cb (with a subsequent adjustment in c/s
> 25869:59b3663316db).
> 
> >> b) we could insert the context entry in the fault handler, assuming
> >>     the device is able to recover
> > At least current VT-d doesn't have recovery fault supported, so each
> > triggered faults are fatal.
> 
> Fatal in what sense? I would assume that if the driver retries the operation, it
> would succeed if the first fault causes the context entry to be inserted.

If the driver knows the fact, it should work.  For VT-d without fault recovery capability,  it should do nothing for the unknown translations which maybe faked by some malicious devices. 

> >> c) we could provide a command line option to allow fake devices to
> >>     be create
> >
> > Agree, this maybe a feasible solution I can figure out, so far.
> >
> >> d) we could create context entries for all BDFs, whether or not a
> >>     device exists there
> >
> > As I said,  this maybe bring security issue. Even for the
> > iommu-passthrough option,  it is also not suggested to be used if security is
> considered.
> 
> As said - it is clear that the basic thing here (using
> "iommu=dom0-passthrough") is already weakening security. So security isn't
> the concern in this discussion, that's left to whoever is intending to use that
> option.

Okay,  I vote your option C if don't care security. 
Xiantao

  reply	other threads:[~2012-11-14  0:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-05 14:30 iommu=dom0-passthrough behavior Jan Beulich
2012-11-13  0:11 ` Zhang, Yang Z
2012-11-13  8:07   ` Jan Beulich
2012-11-13  8:50     ` Zhang, Xiantao
2012-11-13  9:41       ` Jan Beulich
2012-11-13 11:13         ` Zhang, Yang Z
2012-11-13 11:24           ` Jan Beulich
2012-11-13 15:02             ` Zhang, Xiantao
2012-11-13 15:29               ` Jan Beulich
2012-11-14  0:37                 ` Zhang, Xiantao [this message]
2012-11-14 13:40                   ` Jan Beulich
2012-11-15  8:23                     ` Zhang, Xiantao
2012-11-15  9:05                       ` Jan Beulich
2012-11-16  6:21                         ` Zhang, Xiantao
2012-11-16  8:22                           ` Jan Beulich
2012-11-16  9:26                           ` Jan Beulich
2012-11-16  9:43                             ` Zhang, Xiantao
2012-11-16  9:53                               ` Jan Beulich

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=B6C2EB9186482D47BD0C5A9A4834564403371EA4@SHSMSX101.ccr.corp.intel.com \
    --to=xiantao.zhang@intel.com \
    --cc=JBeulich@suse.com \
    --cc=wei.huang2@amd.com \
    --cc=weiwang.dd@gmail.com \
    --cc=xen-devel@lists.xen.org \
    --cc=yang.z.zhang@intel.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 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.