-by: Matthew Wilcox wi...@linux.intel.com
--
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.
--
To unsubscribe from
. It reduces the amount of work the
driver has to do without requiring any additional work in the core. I
don't see the disadvantage to it.
Reviewed-by: Matthew Wilcox wi...@linux.intel.com
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we understand
tested.
--
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.
--
To unsubscribe from this list: send the line
they wouldn't.
What a lot of drivers seem to do is fall back either to a single MSI or
just pin-based interrupts when they can't get as many interrupts as they
would like. They don't try to get a single MSI-X interrupt. I feel an
update to the MSI-HOWTO coming on.
--
Matthew Wilcox
On Thu, Mar 26, 2009 at 04:15:56PM -0700, Jesse Barnes wrote:
2, avoid using pci_find_ext_capability every time when reading ATS
Invalidate Queue Depth (Matthew Wilcox)
I asked a question about how that was used, and got back a version which
changed how it was done. I still don't have
*sriov;/* SR-IOV capability related */
Should be ifdeffed?
--
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
On Thu, Mar 19, 2009 at 06:20:16PM -0700, Jesse Barnes wrote:
Ok Yu, I'm ready to apply this set, can you send an updated one with
the fixes Matthew mentioned?
And please add Reviewed-by: Matthew Wilcox wi...@linux.intel.com
to each of the patches.
--
Matthew Wilcox
On Sun, Mar 08, 2009 at 04:30:16PM +0200, Avi Kivity wrote:
Matthew Wilcox wrote:
On Tue, Feb 24, 2009 at 12:47:38PM +0200, Avi Kivity wrote:
Do those patches allow using a VF on the host (in other words, does the
kernel emulate config space accesses)?
SR-IOV hardware handles config space
of it.
--
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.
--
To unsubscribe from this list: send the line unsubscribe kvm
://patchwork.kernel.org/patch/8063/
http://patchwork.kernel.org/patch/8064/
http://patchwork.kernel.org/patch/8065/
http://patchwork.kernel.org/patch/8066/
I need to review this driver; I haven't done that yet. Has anyone else?
--
Matthew Wilcox Intel Open Source Technology
;
[...]
}
--
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.
--
To unsubscribe from this list: send the line unsubscribe kvm
device
+ */
+void pci_restore_iov_state(struct pci_dev *dev)
+{
+ if (dev-sriov)
+ sriov_restore_state(dev);
+}
Apart from the design pattern I mentioned in my previous email also
appearing here, I see no problems with this patch.
--
Matthew Wilcox
invoke virtfn_bdf more than
once.
--
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.
--
To unsubscribe from
, dep_link);
I skipped to the end and read patch 7/7 and I still don't understand
what dep_link is for. Can you explain please? In particular, how is it
different from physfn?
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we understand that you're
--
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.
--
To unsubscribe from this list: send the line unsubscribe kvm
to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
and reset; if it works then
the device is assignable.
If we expose a 'reset' file in the /sys/bus/pci/devices/*/ directories
for devices that are resettable, that should be enough, I would think.
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we
clearing this bit.
--
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.
--
To unsubscribe from this list: send the line
On Thu, Feb 12, 2009 at 08:50:32PM +0800, Yu Zhao wrote:
2, avoid using pci_find_ext_capability every time when reading ATS
Invalidate Queue Depth (Matthew Wilcox)
er ... I didn't say it was a problem. I said I couldn't tell if it was a
problem. There's no point in taking up an extra 4
is that the empty ? : is really confusing and
generally to be avoided. GCC should be able to figure out that it's a
pure/const function anyway and avoid recalculating it.
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we understand that you're interested in selling us
resources _not_ in this array (and indeed, I'd like to
see PCI bridges keep their producer resources somewhere other than in
this array). I accept that there are still some problems with this, but
patch #2 moves us further from being able to achieve this goal, not
closer.
--
Matthew Wilcox
don't think we really know what the One True Usage model is for VF
devices. Chris Wright has some ideas, I have some ideas and Yu Zhao has
some ideas. I bet there's other people who have other ideas too.
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we
on patch review.
--
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.
--
To unsubscribe from this list: send the line
this list: send the line unsubscribe linux-pci in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Matthew Wilcox Intel Open Source Technology Centre
Bill, look, we understand that you're interested
changing.
--
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.
--
To unsubscribe from this list: send the line
the number of resources in struct pci_dev instead of putting
the new resources in struct pci_iov?
--
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
On Tue, Oct 14, 2008 at 08:23:34AM +0800, Dong, Eddie wrote:
Matthew Wilcox wrote:
Wouldn't it be more useful to have the iov/N directories
be a symlink to the actual pci_dev used by the virtual
function?
The main concern here is that a VF may be disabed such as when PF enter
D3 state
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
On Tue, Oct 14, 2008 at 12:18:40PM +0800, Dong, Eddie wrote:
Matthew Wilcox wrote:
On Tue, Oct 14, 2008 at 10:14:35AM +0800, Yu Zhao wrote:
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
,
+#endif
+};
From my reading of the SR-IOV spec, this isn't how it's supposed to
work. The device is supposed to be a fully functional PCI device that
on demand can start peeling off virtual functions; it's not supposed to
boot up and initialise all its virtual functions at once.
--
Matthew Wilcox
[PCI_BRIDGE_RESOURCES+i];
-
Er, this is rather important. Why can you just delete it?
--
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
, or is there some hardware that won't work? Or some other
reason I haven't thought of?
--
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
On Tue, Jul 22, 2008 at 09:38:18PM +0200, Julia Lawall wrote:
There is a call to local_irq_restore in the normal exit case, so it would
seem that there should be one on an error return as well.
Patch looks good to me:
Reviewed-by: Matthew Wilcox [EMAIL PROTECTED]
--
Intel are signing my
33 matches
Mail list logo
