On Mon, Feb 09, 2015 at 10:28:49 +0000, Daniel Berrange wrote: > On Fri, Jan 30, 2015 at 02:21:02PM +0100, Peter Krempa wrote: > > WIP: TODO: docs > > > > Also forbid the new device in post parse callback in all driver that > > implement the callback to warn users right away that the device is not > > supported with their hypervisor. > > --- > > docs/schemas/domaincommon.rng | 50 ++++ > > src/bhyve/bhyve_domain.c | 5 +- > > src/conf/domain_conf.c | 317 ++++++++++++++++++++- > > src/conf/domain_conf.h | 33 +++ > > src/libvirt_private.syms | 2 + > > src/libxl/libxl_domain.c | 3 + > > src/lxc/lxc_domain.c | 4 + > > src/openvz/openvz_driver.c | 3 + > > src/qemu/qemu_domain.c | 3 + > > src/qemu/qemu_driver.c | 13 + > > src/qemu/qemu_hotplug.c | 3 + > > src/uml/uml_driver.c | 3 + > > src/xen/xen_driver.c | 3 + > > src/xenapi/xenapi_driver.c | 3 + > > .../qemuxml2argv-memory-hotplug-dimm.xml | 47 +++ > > 15 files changed, 490 insertions(+), 2 deletions(-) > > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-dimm.xml > > > diff --git a/tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-dimm.xml b/tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-dimm.xml > > new file mode 100644 > > index 0000000..2dba8a2 > > --- /dev/null > > +++ b/tests/qemuxml2argvdata/qemuxml2argv-memory-hotplug-dimm.xml > > @@ -0,0 +1,47 @@ > > +<domain type='qemu'> > > ... > > > + <memory model='acpi-dimm'> > > + <source> > > + <nodemask>2-5,7</nodemask> > > So, this is the host NUMA node that it is allocate from > > > + <pagesize unit='KiB'>4</pagesize> > > The host huge page size to use > > > + </source> By the way, the <source> subelement is optional and if not provided the config in <numatune> and <cpu> is used to infer the correct data. (In case it wasn't obvious as it's lacking docs) > > + <target> > > + <size unit='KiB'>123456</size> > > The guest memory size > > > + <node>0</node> > > The guest NUMA node > > > + </target> > > + </memory> > > This isn't showing use of the <address type="acpi-dimm"> address. Is that > always an output-only thing, or can apps provide that upfront like they > do for other address types. The apps will be able to provide it if needed, but having the physical offset of the module specified doesn't really seem to be a generally useful case. Currently the address is updated in the live definiton to carry accross migrations. In case the user specified the address it will be still queried and updated in the XML in case qemu would align the address so that migration will work even in case the alignment rules would change. I'll add a case where the address is specified to the test case. Peter
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list