Re: [RFC PATCH 05/12] conf: Add interface to parse and format memory device information

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]