[openstack-dev] [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.
Daniel P. Berrange
berrange at redhat.com
Thu Nov 13 17:43:14 UTC 2014
On Thu, Nov 13, 2014 at 09:36:18AM -0800, Dan Smith wrote:
> > That sounds like something worth exploring at least, I didn't know
> > about that kernel build option until now :-) It sounds like it ought
> > to be enough to let us test the NUMA topology handling, CPU pinning
> > and probably huge pages too.
> Okay. I've been vaguely referring to this as a potential test vector,
> but only just now looked up the details. That's my bad :)
> > The main gap I'd see is NUMA aware PCI device assignment since the
> > PCI <-> NUMA node mapping data comes from the BIOS and it does not
> > look like this is fakeable as is.
> Yeah, although I'd expect that the data is parsed and returned by a
> library or utility that may be a hook for fakeification. However, it may
> very well be more trouble than it's worth.
> I still feel like we should be able to test generic PCI in a similar way
> (passing something like a USB controller through to the guest, etc).
> However, I'm willing to believe that the intersection of PCI and NUMA is
> a higher order complication :)
Oh I forgot to mention with PCI device assignment (as well as having a
bunch of PCI devices available), the key requirement is an IOMMU.
AFAIK, neither Xen or KVM provide any IOMMU emulation, so I think we're
out of luck for even basic PCI assignment testing inside VMs.
 Devices which provide function level reset or PM reset capabilities,
as bus level reset is too painful to deal with, requiring co-assignment
of all devices on the same bus to the same guest.
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the OpenStack-dev