Re: [Xen-devel] Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 06/06/2016 04:41 AM, Jan Beulich wrote:
>
>> - on the DomU - when I run that "test console" tool, the "lspci -xxx" 
>> output is different from before/after
>> not much, though, only one register(?)
>>
>> diff lspci.before-testconsole lspci.after-testconsole
>> 2c2
>> < 00: cf 15 00 00 02 01 00 02 00 00 00 ff 00 40 00 00
>> ---
>>> 00: cf 15 00 00 02 01 00 02 00 00 00 ff 00 00 00 00
> Okay, that's the Latency Timer field, and I think just like BARs we
> may need to permit restoring this field. However, please note that
> the reset being done behind the back of pciback really is the
> problem here: pciback assumes (for a reason, as you can certainly
> understand) that it has full control over config space of a passed
> through device.
>
> And actually the latency timer would, as a side effect of enabling
> bus mastering on the device (via the pci_set_master() call from
> command_write()) set the Latency Timer field properly, just that
> again pciback (and the rest of Dom0's PCI subsystem) thinks that
> bus mastering is already enabled on the device. So perhaps in
> permissive mode we should simply allow the latency timer field to
> be written, just like we allow writing various of the Command
> Register bits in that mode. Maintainers, what do you think?

Don't we currently allow it to be written unconditionally? It is no
different from accessing Cache Line Size.

Or are you suggesting to make it stricter?

>
> If we decide to go that route, I would then wonder whether
> Cache Line Size being unconditionally writable right now would
> also better be restricted to permissive mode.


-boris


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