| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: enable_ats_device() call site
>>> On 18.08.11 at 01:27, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> wrote:
>> what is the reason for calling this from VT-d's domain_context_mapping()?
>> I neither undertsand why this is VT-d specific, nor why it needs to be
>> re-done with each device re-assignment.
>
> The reason is FLR clears the ATS enabled bit so we need to re-enable it for
> every re-assignment. The reason we don't need to do this for ACS might be
> ACS
> reside on the bridge, not in the PCI endpoint. ATS on the other hand,
> resides in PCI endpoints.
And why is it VT-d specific then? The problem to solve is that enabling
may not happen when it is first attempted, in the case where Xen on its
own can't be certain that using MMCFG is safe. Hence when the device
gets reported by Dom0 (or when MMCFG gets enabled for the respective
bus), another attempt needs to be made at enabling it. De-assigning and
then re-assigning the device to Dom0 seems to be overkill to me.
>> Alternatively - why do we need scan_pci_devices() at all? We're
>> supposed to be getting the devices reported from Dom0 anyway
>
> Looks like it is use for building bus2bridge[] which is used for figuring
> out upstream bridges which are needed when assigning non-PCIe devices.
Oh, right, I keep forgetting that, especially as that puts under question
why we have Dom0 report non-extfn, non-virtfn devices at all. And
perhaps we should issue a warning if Dom0 reports such a device that
we didn't know about already?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home