From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Zhang, Xiantao" <xiantao.zhang@intel.com>
Cc: "Hao, Xudong" <xudong.hao@intel.com>,
Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback
Date: Tue, 22 May 2012 16:34:14 -0400 [thread overview]
Message-ID: <20120522203414.GA18877@phenom.dumpdata.com> (raw)
In-Reply-To: <B6C2EB9186482D47BD0C5A9A48345644146613@SHSMSX101.ccr.corp.intel.com>
On Tue, May 22, 2012 at 01:57:44AM +0000, Zhang, Xiantao wrote:
> Hi, Jan/Konrad
> Do you have further comments about this patch ? Thanks!
Well .. What about making this be in the generic code? That way
both KVM and Xen can benefit? And also then the default values
don't have to show up in two places.
> Xiantao
>
> > -----Original Message-----
> > From: Hao, Xudong
> > Sent: Wednesday, May 09, 2012 2:26 PM
> > To: Jan Beulich; Konrad Rzeszutek Wilk
> > Cc: xen-devel; Zhang, Xiantao
> > Subject: RE: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is
> > owned by pciback
> >
> > > -----Original Message-----
> > > From: Jan Beulich [mailto:JBeulich@suse.com]
> > > Sent: Tuesday, May 08, 2012 5:42 PM
> > > To: Hao, Xudong; Konrad Rzeszutek Wilk
> > > Cc: xen-devel
> > > Subject: Re: [Xen-devel] [PATCH v2] Re-enable LTR/OBFF when device is
> > > owned by pciback
> > >
> > > >>> On 08.05.12 at 11:05, "Hao, Xudong" <xudong.hao@intel.com> wrote:
> > > >> -----Original Message-----
> > > >> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] On Sun,
> > > >> May 06, 2012 at 07:35:47AM +0000, Hao, Xudong wrote:
> > > >> > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> > > >> > > Don't you need to disable this when the device is un-assigned
> > > >> > > from the
> > > >> guest?
> > > >> > >
> > > >> >
> > > >> > I don't think this need to be disabled when device is un-assigned
> > > >> > from
> > > > guest.
> > > >> If host want to use device again, the host device driver need
> > > >> re-load, so whether disabling ltr/obff is up to host device driver.
> > > >>
> > > >> What if the driver isn't doing that?
> > > >
> > > > Make it clear, here host side do not be considered, host has its own
> > driver.
> > > > The only thing is to make sure ltr/obff is enabled before assigning
> > > > guest, so that benefit on power.
> > > >
> > > > Since device is owned by pciback again when it un-assigned from
> > > > guest, we need not disable explicitly.
> > >
> > > As you didn't answer my respective earlier question - _if_ this is a
> > > feature needing enabling (and parameter tweaking), I'd imply there are
> > > possible incompatibilities (i.e. reasons for not enabling this
> > > always), and hence this shouldn't be done universally (and with fixed
> > > values for the parameters) _and_ should be properly reset.
> > >
> > Only Xen administrator can hide a device by pciback, and can assign a device
> > to guest. These power feature such as ltr and obff should be enabled by a
> > sys-admin, I do not know which situation is a possible disabling these
> > features, and why sys-admin want to disable them?
next prev parent reply other threads:[~2012-05-22 20:34 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-04 7:49 [PATCH v2] Re-enable LTR/OBFF when device is owned by pciback Hao, Xudong
2012-05-04 8:07 ` Jan Beulich
2012-05-06 8:10 ` Hao, Xudong
2012-05-07 7:24 ` Jan Beulich
2012-05-07 7:39 ` Hao, Xudong
2012-05-04 13:20 ` Konrad Rzeszutek Wilk
2012-05-06 7:35 ` Hao, Xudong
2012-05-07 13:54 ` Konrad Rzeszutek Wilk
2012-05-08 9:05 ` Hao, Xudong
2012-05-08 9:41 ` Jan Beulich
2012-05-09 6:25 ` Hao, Xudong
2012-05-22 1:57 ` Zhang, Xiantao
2012-05-22 7:21 ` Jan Beulich
2012-05-23 14:45 ` Zhang, Xiantao
2012-05-23 15:07 ` Jan Beulich
2012-05-25 3:42 ` Zhang, Xiantao
2012-05-22 20:34 ` Konrad Rzeszutek Wilk [this message]
2012-05-23 14:50 ` Zhang, Xiantao
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=20120522203414.GA18877@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xen.org \
--cc=xiantao.zhang@intel.com \
--cc=xudong.hao@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).