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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 15.06.16 at 12:45, <andrey2805@gmail.com> wrote:
> In reply to -
> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html 
> 
> HI, I am working with Jurgen on the issue, as per Jan's request I tried to
> write explicitly only latency timer to be written -
> bool force_write = false;
> if ((dev_data->permissive || xen_pcibk_permissive) &&
>               offset == PCI_CACHE_LINE_SIZE && size == 4)
>              force_write = true;
> ...
> 
> if ((force_write || !handled) && !err) {...}
> 
> But then it exposed another issue, the command register field seems not to
> be restored also
> because I think the bits which are to be restored are not
> in PCI_COMMAND_GUEST mask.

Please be more precise: Which bits in particular are not getting
set back to the needed values (I would guess the memory
and/or I/O decode ones, which we specifically must not allow
the guest to control, but I'd like to be certain)?

If my guess is correct, then I think rather than adding some
hackish workaround to pciback you'd better see whether there's
a way to cause a pci_disable_device() through your driver before
the reset, and a pci_enable_device() after. Or actually, I think
you can do this via plain config space writes from your driver: Try
writing the Command Register with the two decode bits clear
right before restoring the intended value (see the logic close to
the top of command_write()).

Jan


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