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 accesses to virtual functions. No
kernel changes needed for that aspect 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."
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 accesses to virtual functions. No
> kernel changes needed for that aspect of it.
>
Patches 2 and 3 of the patchset that enables SR/IOV in kvm [1] suggest
that at the config space is only partially implemented.
[1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/29034
--
error compiling committee.c: too many arguments to function
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 accesses to virtual functions. No
> >kernel changes needed for that aspect of it.
>
> Patches 2 and 3 of the patchset that enables SR/IOV in kvm [1] suggest
> that at the config space is only partially implemented.
>
> [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/29034
I believe Red Hat are now members of the PCI SIG, you really should
download the SR-IOV spec that Yu Zhao keeps pointing at. It's going to
be very hard to have a sensible discussion if you haven't read 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."
On Sun, Mar 08, 2009 at 09:01:09AM -0600, Matthew Wilcox wrote:
> 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 accesses to virtual functions. No
> > >kernel changes needed for that aspect of it.
> >
> > Patches 2 and 3 of the patchset that enables SR/IOV in kvm [1] suggest
> > that at the config space is only partially implemented.
> >
> > [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/29034
>
> I believe Red Hat are now members of the PCI SIG, you really should
> download the SR-IOV spec that Yu Zhao keeps pointing at. It's going to
> be very hard to have a sensible discussion if you haven't read it.
But if any kernel developers are working for companies that are not
members of the PCI SIG, and wish to read the PCI specs, please let me
know as we are working to enable this to happen through the Linux
Foundation.
thanks,
greg k-h
On Sunday 08 March 2009 22:30:16 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 accesses to virtual functions. No
> > kernel changes needed for that aspect of it.
>
> Patches 2 and 3 of the patchset that enables SR/IOV in kvm [1] suggest
> that at the config space is only partially implemented.
>
> [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/29034
Hi Avi
For kernel side, patch 2 is not necessary. Because kernel would read VID/DID
directly from pci_dev rather than configuration space, which have been set
properly already.
And very sorry, for the patch 3. We haven't known exactly what's happened. I
think the problem is caused by guest driver, but didn't confirm(and I have
some misunderstandings with ZhaoYu for I thought we are agree on the reason,
but after confirm with him, he didn't agree). I am doing more investigations
to find the real cause.
--
regards
Yang, Sheng
On Monday 09 March 2009 11:42:05 Yang, Sheng wrote:
> On Sunday 08 March 2009 22:30:16 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 accesses to virtual functions. No
> > > kernel changes needed for that aspect of it.
> >
> > Patches 2 and 3 of the patchset that enables SR/IOV in kvm [1] suggest
> > that at the config space is only partially implemented.
> >
> > [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/29034
>
> Hi Avi
>
> For kernel side, patch 2 is not necessary. Because kernel would read
> VID/DID directly from pci_dev rather than configuration space, which have
> been set properly already.
>
> And very sorry, for the patch 3. We haven't known exactly what's happened.
> I think the problem is caused by guest driver, but didn't confirm(and I
> have some misunderstandings with ZhaoYu for I thought we are agree on the
> reason, but after confirm with him, he didn't agree). I am doing more
> investigations to find the real cause.
Found the reason of patch 3.
After insert guest driver module(vf driver), the driver would do a RMW to the
command register to enable Bus Master bit(bit 2). And before that, MMIO bit
have been set in the register. But without the patch 3, guest driver won't see
the MMIO bit(bit 1), then just set 0x4 to the command register, with the side
effect to unmap MMIO in QEmu. So patch 3 is needed(and what I thought before
is right).
Unset the bit only affect the QEmu, which would unmap the mapping for MMIO.
Kernel side don't need this, so it's OK.
--
regards
Yang, Sheng
Yang, Sheng wrote:
>>> Patches 2 and 3 of the patchset that enables SR/IOV in kvm [1] suggest
>>> that at the config space is only partially implemented.
>>>
>>> [1] http://thread.gmane.org/gmane.comp.emulators.kvm.devel/29034
>>>
>> Hi Avi
>>
>> For kernel side, patch 2 is not necessary. Because kernel would read
>> VID/DID directly from pci_dev rather than configuration space, which have
>> been set properly already.
>>
>> And very sorry, for the patch 3. We haven't known exactly what's happened.
>> I think the problem is caused by guest driver, but didn't confirm(and I
>> have some misunderstandings with ZhaoYu for I thought we are agree on the
>> reason, but after confirm with him, he didn't agree). I am doing more
>> investigations to find the real cause.
>>
>
> Found the reason of patch 3.
>
> After insert guest driver module(vf driver), the driver would do a RMW to the
> command register to enable Bus Master bit(bit 2). And before that, MMIO bit
> have been set in the register. But without the patch 3, guest driver won't see
> the MMIO bit(bit 1), then just set 0x4 to the command register, with the side
> effect to unmap MMIO in QEmu. So patch 3 is needed(and what I thought before
> is right).
>
> Unset the bit only affect the QEmu, which would unmap the mapping for MMIO.
> Kernel side don't need this, so it's OK.
>
Thanks for the explanations!
--
error compiling committee.c: too many arguments to function