[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 06.06.16 at 11:09, <juwalter@xxxxxxxxx> wrote:
> [ 1466.964895 <    0.000023>] xen-pciback: 0000:06:00.0: write request 4 
> bytes at 0xc = 4000
> [ 1466.964897 <    0.000002>] xen-pciback: 0000:06:00.0: read 1 bytes at 
> 0xc
> [ 1466.964907 <    0.000010>] xen-pciback: 0000:06:00.0: read 1 bytes at 
> 0xc = 0
> [ 1466.964914 <    0.000007>] xen-pciback: 0000:06:00.0: read 1 bytes at 
> 0xf
> [ 1466.964925 <    0.000011>] xen-pciback: 0000:06:00.0: read 1 bytes at 
> 0xf = 0

No read of 0xd and 0xe?

> I agree that it is very ugly to reset the device behind the back of 
> pciback.
> However, this is how the vendor decided to do it, and have no better 
> idea how
> to accomplish this.
> While I cannot image that there is, but can you think think of
> any "correct" way to reset a pci device from
>       a) inside a DomU
>       b) from the user space library?

No, resetting a device shouldn't be needed at all _after_ assignment
to a guest. Do you have any insight why that's needed here in the
first place?

>> 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?
> (is that something that /sys/bus/pci/drivers/pciback/quirks could
> help with? according to docs, this is only used/in effect when
> in permissive mode)

I don't think so - quirks can, afaict, only be registered for fields that
don't have explicit handling associated to them (see the
xen_pcibk_field_is_dup() call in xen_pcibk_config_add_field_offset()).

>> 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.
>> In any event, Jürgen, it would be helpful if you could confirm
> If I understood you correctly, I modify xen_pcibk_config_write
> in "drivers/xen/xen-pciback/conf_space.c" to specifically allow only
> this field (latency timer) to be written and log everything.

Right - just limit your existing workaround to just this one field.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.