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

>>> 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.

>> 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.

Jan

  reply	other threads:[~2012-11-13 15:29 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 [this message]
2012-11-14  0:37                 ` Zhang, Xiantao
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=50A2755402000078000A837D@nat28.tlf.novell.com \
    --to=jbeulich@suse.com \
    --cc=wei.huang2@amd.com \
    --cc=weiwang.dd@gmail.com \
    --cc=xen-devel@lists.xen.org \
    --cc=xiantao.zhang@intel.com \
    --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.