<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 25, 2014 at 2:01 PM, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>><br>
> To: "Dan Smith" <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>><br>
><br>
> On Thu, Nov 13, 2014 at 05:43:14PM +0000, Daniel P. Berrange wrote:<br>
> > On Thu, Nov 13, 2014 at 09:36:18AM -0800, Dan Smith wrote:<br>
> > > > That sounds like something worth exploring at least, I didn't know<br>
> > > > about that kernel build option until now :-) It sounds like it ought<br>
> > > > to be enough to let us test the NUMA topology handling, CPU pinning<br>
> > > > and probably huge pages too.<br>
> > ><br>
> > > Okay. I've been vaguely referring to this as a potential test vector,<br>
> > > but only just now looked up the details. That's my bad :)<br>
> > ><br>
> > > > The main gap I'd see is NUMA aware PCI device assignment since the<br>
> > > > PCI <-> NUMA node mapping data comes from the BIOS and it does not<br>
> > > > look like this is fakeable as is.<br>
> > ><br>
> > > Yeah, although I'd expect that the data is parsed and returned by a<br>
> > > library or utility that may be a hook for fakeification. However, it may<br>
> > > very well be more trouble than it's worth.<br>
> > ><br>
> > > I still feel like we should be able to test generic PCI in a similar way<br>
> > > (passing something like a USB controller through to the guest, etc).<br>
> > > However, I'm willing to believe that the intersection of PCI and NUMA is<br>
> > > a higher order complication :)<br>
> ><br>
> > Oh I forgot to mention with PCI device assignment (as well as having a<br>
> > bunch of PCI devices available[1]), the key requirement is an IOMMU.<br>
> > AFAIK, neither Xen or KVM provide any IOMMU emulation, so I think we're<br>
> > out of luck for even basic PCI assignment testing inside VMs.<br>
><br>
> Ok, turns out that wasn't entirely accurate in general.<br>
><br>
> KVM *can* emulate an IOMMU, but it requires that the guest be booted<br>
> with the q35 machine type, instead of the ancient PIIX4 machine type,<br>
> and also QEMU must be launched with "-machine iommu=on". We can't do<br>
> this in Nova, so although it is theoretically possible, it is not<br>
> doable for us in reality :-(<br>
><br>
> Regards,<br>
> Daniel<br>
<br>
</div></div>Is it worth still pursuing virtual testing of the NUMA awareness work you, nikola, and others have been doing? It seems to me it would still be preferable to do this virtually (and ideally in the gate) wherever possible?<br></blockquote><div><br></div><div>The more we can test in the gate and without real hardware the better.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
<br>
Steve<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>