On 08.06.2015 15:42, James Cowgill wrote:

I see no reason to duplicate this list of architectures. This also allows more guest architectures to be used with libvirt (like the mips64el qemu machine I am trying to run).

Signed-off-by: James Cowgill <james410@cowgill.org.uk> --- docs/schemas/domaincommon.rng | 26 ++++++-------------------- 1 file changed, 6 insertions(+), 20 deletions(-)

diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 7c6fa5c..fc28fb3 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -331,7 +331,9 @@ <define name="ostypehvm"> <element name="type"> <optional> - <ref name="archList"/> + <attribute name="arch"> + <ref name="archnames"/> + </attribute> </optional> <optional> <attribute name="machine"> @@ -344,29 +346,13 @@ </element> </define>

- <define name="archList"> - <attribute name="arch"> - <choice> - <value>armv7l</value> - <value>aarch64</value> - <value>i686</value> - <value>x86_64</value> - <value>mips</value> - <value>ppc</value> - <value>ppc64</value> - <value>ppc64le</value> - <value>s390</value> - <value>s390x</value> - <value>sparc</value> - </choice> - </attribute> - </define> - <define name="osexe"> <element name="os"> <element name="type"> <optional> - <ref name="archList"/> + <attribute name="arch"> + <ref name="archnames"/> + </attribute> </optional> <value>exe</value> </element>

The patch looks good to me. ACked and pushed. Although during testing I've found 2 small bugs (for which I'm going to propose patches in a while) and one big issue that I'm not sure how to fix. The problem is, imagine you have some system-wide qemus installed. Say for x86_64 and ppc. Then, you have qemu.git where you have all arches built. Therefore, in order to use them, you put something like this into the xml: <emulator>/path/to/qemu.git/mips64el-softmmu/qemu-system-mips64el</emulator> But defining such domain fails, since the emulator is not in the capabilities (virsh capabilities) - it's not system wide emulator installed under $PATH. Sigh. We need those capabilities in order to check whether the emulator supports desired architecture from the xml. However, the capabilities construction is driver dependent - caps for qemu binaries are constructed differently than for VBOX or XEN server, right? Frankly, I don't have any bright idea how to fix this. If anybody has, please enlighten me. Michal