Re: [Xen-devel] iommu=dom0-passthrough behavior

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.11.12 at 16:02, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> > 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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel