On Tue, 2018-11-27 at 20:37 +0100, infos(a)nafets.de 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....
- dtb
https://github.com/dhruvvyas90/qemu-rpi-kernel/blob/master/versatile-pb.d...
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