From: "Jan Beulich" <JBeulich@suse.com>
To: "Jürgen Walter" <juwalter@gmail.com>
Cc: Juergen Gross <JGross@suse.com>,
xen-devel@lists.xen.org, David Vrabel <david.vrabel@citrix.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Sylwester Sosnowski <syso@datanoise.net>
Subject: Re: Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6
Date: Mon, 06 Jun 2016 03:43:09 -0600 [thread overview]
Message-ID: <575561CD02000078000F1E98@prv-mh.provo.novell.com> (raw)
In-Reply-To: <D2095C89-D1EC-4739-BF68-418825C0BADE@gmail.com>
>>> On 06.06.16 at 11:09, <juwalter@gmail.com> 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.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-06 9:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-02 19:59 Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6 Sylwester Sosnowski
2016-06-02 20:06 ` Konrad Rzeszutek Wilk
2016-06-02 20:11 ` Sylwester Sosnowski
2016-06-03 7:24 ` Sylwester Sosnowski
2016-06-03 11:52 ` Jan Beulich
2016-06-03 12:02 ` Jürgen Walter
2016-06-03 13:26 ` Jan Beulich
2016-06-03 14:20 ` Jan Beulich
2016-06-04 14:36 ` Jürgen Walter
2016-06-06 7:59 ` Jan Beulich
2016-06-04 15:15 ` Jürgen Walter
2016-06-06 8:41 ` Jan Beulich
2016-06-06 9:09 ` Jürgen Walter
2016-06-06 9:43 ` Jan Beulich [this message]
2016-06-06 14:01 ` Boris Ostrovsky
2016-06-06 14:21 ` Jan Beulich
2016-06-06 14:45 ` Boris Ostrovsky
-- strict thread matches above, loose matches on Subject: below --
2016-06-15 10:45 Andrey Grodzovsky
2016-06-15 13:14 ` Jan Beulich
2016-06-18 3:24 ` Andrey Grodzovsky
2016-06-20 6:57 ` Jan Beulich
2016-06-02 19:49 Sylwester Sosnowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=575561CD02000078000F1E98@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=JGross@suse.com \
--cc=boris.ostrovsky@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=juwalter@gmail.com \
--cc=syso@datanoise.net \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).