From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>,
Asit K Mallick <asit.k.mallick@intel.com>,
Donald D Dugger <donald.d.dugger@intel.com>,
Jun Nakajima <jun.nakajima@intel.com>,
xen-devel <xen-devel@lists.xenproject.org>,
xiantao.zhang@intel.com
Subject: Re: [PATCH 3/3] passthrough: allow to suppress SERR and PERR signaling altogether
Date: Mon, 7 Apr 2014 14:17:01 +0100 [thread overview]
Message-ID: <5342A54D.7040708@citrix.com> (raw)
In-Reply-To: <5342BEAA02000078000062E9@nat28.tlf.novell.com>
On 07/04/14 14:05, Jan Beulich wrote:
>>>> On 07.04.14 at 14:47, <andrew.cooper3@citrix.com> wrote:
>> On 03/04/14 10:41, Jan Beulich wrote:
>>> + if ( val & PCI_STATUS_CHECK )
>>> + {
>>> + printk(XENLOG_INFO "%04x:%02x:%02x.%u status %04x\n",
>>> + seg, bus, dev, func, val);
>> What is the purpose of this printk? From the text alone it is not obvious.
> It's simply to have an indication that the status register was written
> (and that certain bits may have got cleared).
Then at the very least it should be ..."status %04x -> %04x\n", ....
val, val & PCI_STATUS_CHECK) to identify which status bits are being
cleared.
>
>>> + pci_conf_write16(seg, bus, dev, func, PCI_STATUS, val);
>> I dont think this code has any right to clear status bits other than the
>> ones it is checking for, so the write should be "val & PCI_STATUS_CHECK"
> Hmm, the intention is to clear all status fields that can be cleared, and
> the if() around the write is just to avoid the printk() and the write if
> possible. PCI_STATUS_CHECK already includes all changeable bits, and
> I'd expect any of the few that are currently reserved to get added
> here, should they attain a meaning of a writable one.
>
> Jan
>
For forward compatibility, we must not assume anything about currently
reserved bits which Xen doesn't know about.
If PCI_STATUS_CHECK is intended to be extended with future clearable
bits, perhaps naming it "PCI_STATUS_CLEARABLE" would be clearer.
~Andrew
next prev parent reply other threads:[~2014-04-07 13:17 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-03 9:33 [PATCH 0/3] fixes (read: workarounds) for XSA-59 Jan Beulich
2014-04-03 9:39 ` [PATCH 1/3] VT-d: suppress UR signaling for server chipsets Jan Beulich
2014-04-07 12:12 ` Andrew Cooper
2014-04-07 13:11 ` Jan Beulich
2014-04-03 9:40 ` [PATCH 2/3] VT-d: suppress UR signaling for desktop chipsets Jan Beulich
2014-04-07 12:21 ` Andrew Cooper
2014-04-03 9:41 ` [PATCH 3/3] passthrough: allow to suppress SERR and PERR signaling altogether Jan Beulich
2014-04-07 10:05 ` Andrew Cooper
2014-04-07 10:21 ` Jan Beulich
2014-04-07 12:47 ` Andrew Cooper
2014-04-07 13:05 ` Jan Beulich
2014-04-07 13:17 ` Andrew Cooper [this message]
2014-04-07 13:43 ` Jan Beulich
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=5342A54D.7040708@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=asit.k.mallick@intel.com \
--cc=donald.d.dugger@intel.com \
--cc=jun.nakajima@intel.com \
--cc=keir@xen.org \
--cc=xen-devel@lists.xenproject.org \
--cc=xiantao.zhang@intel.com \
/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).