From: Matthew Wilcox <matthew@wil.cx>
To: Yu Zhao <yu.zhao@intel.com>
Cc: eddie.dong@intel.com,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Randy Dunlap <randy.dunlap@oracle.com>,
Grant Grundler <grundler@parisc-linux.org>,
Alex Chiang <achiang@hp.com>, Roland Dreier <rdreier@cisco.com>,
Greg KH <greg@kroah.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>
Subject: Re: [PATCH 6/6 v3] PCI: document the change
Date: Mon, 13 Oct 2008 22:01:05 -0600 [thread overview]
Message-ID: <20081014040105.GA25780@parisc-linux.org> (raw)
In-Reply-To: <20081014021435.GA1482@yzhao12-linux.sh.intel.com>
On Tue, Oct 14, 2008 at 10:14:35AM +0800, Yu Zhao wrote:
> > BTW, the SR-IOV patch is not only for network, some other devices such as IDE will use same code base as well and we image it could have other parameter to set such as starting LBA of a IDE VF.
>
> As Eddie said, we have two problems here:
> 1) User has to set device specific parameters of a VF when he wants to
> use this VF with KVM (assign this device to KVM guest). In this case,
> VF driver is not loaded in the host environment. So operations which
> are implemented as driver callback (e.g. set_mac_address()) are not
> supported.
I suspect what you want to do is create, then configure the device in
the host, then assign it to the guest.
> 2) For security reason, some SR-IOV devices prohibit the VF driver
> configuring the VF via its own register space. Instead, the configurations
> must be done through the PF which the VF is associated with. This means PF
> driver has to receive parameters that are used to configure its VFs. These
> parameters obviously can be passed by traditional tools, if without
> modification for SR-IOV.
I think that idea also covers this point.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
next prev parent reply other threads:[~2008-10-14 4:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-27 8:28 [PATCH 6/6 v3] PCI: document the change Zhao, Yu
2008-10-01 16:07 ` Matthew Wilcox
2008-10-14 0:23 ` Dong, Eddie
2008-10-14 1:08 ` Matthew Wilcox
2008-10-14 2:31 ` Dong, Eddie
2008-10-14 2:14 ` Yu Zhao
2008-10-14 4:01 ` Matthew Wilcox [this message]
2008-10-14 4:06 ` Yu Zhao
2008-10-14 4:18 ` Dong, Eddie
2008-10-14 4:46 ` Matthew Wilcox
2008-10-17 5:48 ` Anirban Chakraborty
2008-11-15 12:38 ` Yu Zhao
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=20081014040105.GA25780@parisc-linux.org \
--to=matthew@wil.cx \
--cc=achiang@hp.com \
--cc=eddie.dong@intel.com \
--cc=greg@kroah.com \
--cc=grundler@parisc-linux.org \
--cc=jbarnes@virtuousgeek.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=rdreier@cisco.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=yu.zhao@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).