[libvirt] [RFC] phi support in libvirt

Daniel P. Berrange berrange at redhat.com
Fri Jan 6 11:50:45 UTC 2017


(btw, if possible please try to avoid sending HTML email, or HTML+text
email to the list - plaintext oinly email is preferred)

On Mon, Dec 26, 2016 at 07:57:42PM +0800, Feng, Shaohe wrote:
> for the NUMA format,
> we still uses "memory" to describe the mcdram.
> But we remove the cpus elements.
> <numa>
>   <cell id='3' memory='8' unit='GiB'/> </numa>
>   <cell id='4' memory='8' unit='GiB'/> </numa>
> 
> At present, for this kind CPUless NUMA , we only support mcdram as memroy
> backend.

Yep, that sounds ok.

> 
> <domain>
>   ...
>   <memoryBacking>
>     <mcdram nodeset="3-4"/>
>   </memoryBacking>
> </domain>
> 
> And we reject a CPUless NUMA without memroy backend.
> Maybe we will allow it in futures after qemu can handle it well.

Yes, that's ok too.

> A question:
> 1. Should libvirt probe the "host-nodes" for this kind of memory to make a
> smart map?
> 
> The qemu arguments will be as follow:
> -object
> memory-backend-ram,size=8G,prealloc=yes,host-nodes=0,policy=bind,id=node3 \
> -numa node,nodeid=3,memdev=node3 \
> 
> -object
> memory-backend-ram,size=8G,prealloc=yes,host-nodes=0,policy=bind,id=node4 \
> -numa node,nodeid=4,memdev=node4 \
> 
> 
> 2. or we let user specify the host-nodes.
>   <memoryBacking>
>     <mcdram nodeset="3-4", host-nodes="0-1"/>
>   </memoryBacking>
> </domain>

You don't need to do that  - <numatune> already lets the user say
which host node, each guest node is attached to

http://libvirt.org/formatdomain.html#elementsNUMATuning

  <numatune>
    <memory mode="strict" nodeset="1-4,^3"/>
    <memnode cellid="0" mode="strict" nodeset="1"/>
    <memnode cellid="2" mode="preferred" nodeset="2"/>
  </numatune>


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|




More information about the libvir-list mailing list