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 -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
