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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.06.16 at 05:24, <andrey2805@xxxxxxxxx> wrote:
> On Wed, Jun 15, 2016 at 9:14 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>> On 15.06.16 at 12:45, <andrey2805@xxxxxxxxx> 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)?
> 
> Indeed, 0x103 which would be  MEMORY,IO and SERR.
> 
>> 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()).
>>
>> So i tried the first option, as you suggested by writing
> to /sys/bus/pci/devices/0000\:00\:00.0/enable
> '0' == disable before reset and '1' == enable after from the test app, but
> no writes get through to pic-back on DOM0 , only the reads.
> But this basically still tries to write the MEMORY and IO bits to command
> register down the call stack in pci_enable_resources
> <http://lxr.free-electrons.com/ident?i=pci_enable_resources>
> which would again be blocked in xen-pciback xen_pcibk_config_write or am I
> missing something ?

I don't think it would get entirely blocked: What you really need to
look at (and perhaps add some logging to) is command_write()'s logic
involving pci_is_enabled() and is_enable_cmd(). (And I'm not, btw,
convinced that you writing the  enable sysfs node you can achieve
the desired effects. As said - I think you should do plain config space
writes.)

Jan


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