On Tue, 2018-11-27 at 20:37 +0100, infos@xxxxxxxxx wrote: > > What OS did you run inside the guest? I would like to give this a try myself. > > I use: > - Arch Linux ARM http://os.archlinuxarm.org/os/ArchLinuxARM-rpi-latest.tar.gz > - Kernel https://github.com/dhruvvyas90/qemu-rpi-kernel/blob/master/kernel-qemu-4.14.50-stretch?raw=true > - dtb https://github.com/dhruvvyas90/qemu-rpi-kernel/blob/master/versatile-pb.dtb?raw=true > with > virt-install --name vPiBuildTest --virt-type qemu --memory 256 --vcpus=1 --import --disk /data/test/pibuild/vPiBuildTest-sys.raw,format=raw,bus=scsi --events on_crash=restart --noautoconsole --noreboot --net none --arch armv6l --cpu arm1176 --machine versatilepb --boot "kernel=/data/test/pibuild/kernel-qemu-4.14.50-stretch,dtb=/data/test/pibuild/versatile-pb.dtb,kernel_args=root=/dev/sda2 panic=1 rootfstype=ext4 rw console=ttyAMA0,115200" > > Drawback ist hat loading modules does not work, as the (booted) kernel is not from archlinux distro. Not sure how to solve it, one option ist o create an PKGBUILD fort he kernel from dhruvvyas90. > > But it boots :=) Okay, I'll give it a try. [...] > > > @@ -2199,7 +2199,7 @@ static const char *preferredMachines[] = { > > > NULL, /* VIR_ARCH_NONE (not a real arch :) */ > > > "clipper", /* VIR_ARCH_ALPHA */ > > > - NULL, /* VIR_ARCH_ARMV6L (no QEMU impl) */ > > > + "versatilepb", /* VIR_ARCH_ARMV6L */ > > > "integratorcp", /* VIR_ARCH_ARMV7L */ > > > "integratorcp", /* VIR_ARCH_ARMV7B */ > > > > How did you arrive to the conclusion that versatilepb should be the default > > machine type for the architecture? Given how QEMU works, I would expect it to > > match the ARMv7 default. > > Good point, I just changed it to be able to test. Since you're selecting the machine type explicitly when creating the guest (as you should!), whatever value you have here won't actually matter. > > Note that there's a patch on the list that changes all defaults for ARM > > architectures to NULL, so based on whether that patch is ultimately merged you > > might want to do the same. > > Absolutely, how to proceed? Should I wait for the other patcht o be merged before re-posting an updated patch? That patch has been NACKed, so just use integratorcp instead of versatilepb above and you'll be fine. [...] > > > +<guest> > > > + <os_type>hvm</os_type> > > > + <arch name='armv7l'> > > > + <wordsize>32</wordsize> > > > + <emulator>/usr/bin/qemu-system-arm</emulator> > > > + <machine>versatilepb</machine> > > > + <domain type='qemu'/> > > > + </arch> > > > + </guest> > > > > This looks very wrong - you added support for the ARMv6l architecture, and > > suddenly an entry for the *ARMv7l* architecture popped up! > > > > It's not indented properly, either. Did you add this manually? > > Ups, it´s a typo should have been armv6l, I will correct in an updated patch. > Yes I added it manually, can you point me to a better way? It seems like 'make check' is perfectly happy with that hunk being missing; based on the name of the test that makes sense, since it's probably (I haven't checked) just parsing the information and making sure it validates according to our schema. If you want to include the information, I think the best way to do so would be to execute 'virsh capabilities' while you have your own patched build of libvirtd running, and grabbing the ARMv7l section from there: you'll probably find that it contains way more machine types and some extra information. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
