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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.