xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

  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).