Re: [PATCH 04/11] conf: Add device address type for dimm devices

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

 



On Fri, Feb 20, 2015 at 10:19:53 +0100, Martin Kletzander wrote:
> 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.

That is okay if upstream agrees.

> 
>  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.a

As I've explained a few times already. The management apps ideally
shouldn't pass anything in the address and the data are then recalled
from qemu. I want to avoid by all means doing the magic alignment done
by qemu here since we can recall the data after the module is used.

The only reason the address is required is to allow migrations without
moving the modules around. This is the main reason this is stashed under
the address field and users shouldn't need to set it ... ever.

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]