On Thu, Feb 19, 2015 at 04:38:29PM +0100, Peter Krempa wrote:
ACPI Dimm devices are described by the slot and base address. Add a new
address type to be able to describe such address.
---
docs/schemas/domaincommon.rng | 18 +++++++++++
src/conf/domain_conf.c | 74 ++++++++++++++++++++++++++++++++++++++++++-
src/conf/domain_conf.h | 9 ++++++
3 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index acfa16a..1824741 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3993,6 +3993,18 @@
</attribute>
</optional>
</define>
+ <define name="acpidimmaddress">
+ <optional>
+ <attribute name="slot">
+ <ref name="unsignedInt"/>
+ </attribute>
+ </optional>
+ <optional>
+ <attribute name="base">
+ <ref name="hexuint"/>
+ </attribute>
+ </optional>
+ </define>
<define name="devices">
<element name="devices">
<interleave>
@@ -4407,6 +4419,12 @@
</attribute>
<ref name="isaaddress"/>
</group>
+ <group>
+ <attribute name="type">
+ <value>acpi-dimm</value>
+ </attribute>
+ <ref name="acpidimmaddress"/>
+ </group>
</choice>
</element>
</define>
I've got 2 questions here: 1) Why not just "dimm"? I feel like the "acpi" complicates everything. 2) It looks like we won't do any address validation or allocation, is that planned?. I hope this won't end up like other address types where we just wait for qemu to fail. Also, if base[n+1] is just base[n]+size[n], then there should be no problem assigning proper addresses automatically. I think it'd be much less pain to automatically assign them in libvirt then making it mandatory for the management application.
Attachment:
pgptT7FO1T45z.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list