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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.06.16 at 17:15, <juwalter@xxxxxxxxx> wrote:
> On 3 Jun 2016, at 15:26, Jan Beulich wrote:
>> I'll see to put together a patch for the recognizable problem,
>> but I'm still unclear about your actual one.
> 
> regarding the actual one: while it is still not working, I managed to 
> dig deeper and found a few observations
> 
> background: there is a driver/kernel module, and a user space library, 
> and a "test console"
> the "test console" uses the library, and invokes "cifXInit" (initialise 
> the PCI card)
> 
> during init, it does
> a) read pci config (space)
> b) send reset sequence to the PCI device
> c) writes back the pci config saved from step "a)" (restore)

I'm sorry to mention that, but so far you still didn't provide a
matching pciback log for that portion of the operation, at least
afaict.

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

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
that instead of your gross hack, only permitting the actual write
of that one field would also make the device usable by the guest.

Jan

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