[libvirt] [PATCH 0/2] qemu: arm guest on x86
From: Stefan Schallenberg <nafets227@users.noreply.github.com> *** BLURB HERE *** Stefan Schallenberg (2): Add armv6l Support as guest qemu: Add Default PCI Device for arm guests docs/news.xml | 9 +++++ docs/schemas/basictypes.rng | 1 + src/qemu/qemu_capabilities.c | 5 ++- src/qemu/qemu_command.c | 4 +- src/qemu/qemu_domain.c | 20 ++++++++-- src/qemu/qemu_domain_address.c | 6 ++- tests/capabilityschemadata/caps-qemu-kvm.xml | 10 +++++ tests/testutilsqemu.c | 40 +++++++++++++++++++- 8 files changed, 84 insertions(+), 11 deletions(-) -- 2.19.2
From: Stefan Schallenberg <nafets227@users.noreply.github.com> Support for armv6l qemu guests has been added. Tested with arm1176 CPU on x86. Signed-off-by: Stefan Schallenberg <infos at nafets.de> --- docs/news.xml | 9 +++++ docs/schemas/basictypes.rng | 1 + src/qemu/qemu_capabilities.c | 5 ++- src/qemu/qemu_command.c | 4 +- src/qemu/qemu_domain.c | 11 ++++-- src/qemu/qemu_domain_address.c | 6 ++- tests/capabilityschemadata/caps-qemu-kvm.xml | 10 +++++ tests/testutilsqemu.c | 40 +++++++++++++++++++- 8 files changed, 75 insertions(+), 11 deletions(-) diff --git a/docs/news.xml b/docs/news.xml index 4406aeb775..e3ec371876 100644 --- a/docs/news.xml +++ b/docs/news.xml @@ -25,6 +25,15 @@ <section title="New features"> </section> <section title="Improvements"> + <change> + <summary> + Add armv6l Support as guest + </summary> + <description> + Support for armv6l qemu guests has been added. + Tested with arm1176 CPU on x86. + </description> + </change> </section> <section title="Bug fixes"> </section> diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng index 71a6db3bb4..9a651a4564 100644 --- a/docs/schemas/basictypes.rng +++ b/docs/schemas/basictypes.rng @@ -407,6 +407,7 @@ <value>aarch64</value> <value>alpha</value> <value>armv7l</value> + <value>armv6l</value> <value>cris</value> <value>i686</value> <value>ia64</value> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index fde27010e4..70ecc5bf21 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -624,7 +624,7 @@ static const char *virQEMUCapsArchToString(virArch arch) { if (arch == VIR_ARCH_I686) return "i386"; - else if (arch == VIR_ARCH_ARMV7L) + else if (arch == VIR_ARCH_ARMV6L || arch == VIR_ARCH_ARMV7L) return "arm"; else if (arch == VIR_ARCH_OR32) return "or32"; @@ -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 */ @@ -4177,6 +4177,7 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps, /* GIC capabilities, eg. available GIC versions */ if ((qemuCaps->arch == VIR_ARCH_AARCH64 || + qemuCaps->arch == VIR_ARCH_ARMV6L || qemuCaps->arch == VIR_ARCH_ARMV7L) && virQEMUCapsProbeQMPGICCapabilities(qemuCaps, mon) < 0) goto cleanup; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 23a6661c10..db0ff6da4d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -9203,7 +9203,9 @@ static bool qemuChrIsPlatformDevice(const virDomainDef *def, virDomainChrDefPtr chr) { - if (def->os.arch == VIR_ARCH_ARMV7L || def->os.arch == VIR_ARCH_AARCH64) { + if (def->os.arch == VIR_ARCH_ARMV6L || + def->os.arch == VIR_ARCH_ARMV7L || + def->os.arch == VIR_ARCH_AARCH64) { /* pl011 (used on mach-virt) is a platform device */ if (chr->deviceType == VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL && diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 2f65bbe34e..acf351f878 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -3260,6 +3260,7 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def, addPCIRoot = true; break; + case VIR_ARCH_ARMV6L: case VIR_ARCH_ARMV7L: case VIR_ARCH_AARCH64: addDefaultUSB = false; @@ -3305,7 +3306,6 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def, addPCIRoot = true; break; - case VIR_ARCH_ARMV6L: case VIR_ARCH_ARMV7B: case VIR_ARCH_CRIS: case VIR_ARCH_ITANIUM: @@ -6035,7 +6035,8 @@ qemuDomainDefaultNetModel(const virDomainDef *def, if (ARCH_IS_S390(def->os.arch)) return "virtio"; - if (def->os.arch == VIR_ARCH_ARMV7L || + if (def->os.arch == VIR_ARCH_ARMV6L || + def->os.arch == VIR_ARCH_ARMV7L || def->os.arch == VIR_ARCH_AARCH64) { if (STREQ(def->os.machine, "versatilepb")) return "smc91c111"; @@ -9818,7 +9819,8 @@ bool qemuDomainMachineIsARMVirt(const char *machine, const virArch arch) { - if (arch != VIR_ARCH_ARMV7L && + if (arch != VIR_ARCH_ARMV6L && + arch != VIR_ARCH_ARMV7L && arch != VIR_ARCH_AARCH64) return false; @@ -10624,7 +10626,8 @@ qemuDomainSupportsNicdev(virDomainDefPtr def, virDomainNetDefPtr net) { /* non-virtio ARM nics require legacy -net nic */ - if (((def->os.arch == VIR_ARCH_ARMV7L) || + if (((def->os.arch == VIR_ARCH_ARMV6L) || + (def->os.arch == VIR_ARCH_ARMV7L) || (def->os.arch == VIR_ARCH_AARCH64)) && net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_VIRTIO_MMIO && net->info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI) diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c index 73ed9cc68c..4cee6633ac 100644 --- a/src/qemu/qemu_domain_address.c +++ b/src/qemu/qemu_domain_address.c @@ -468,7 +468,8 @@ static void qemuDomainAssignARMVirtioMMIOAddresses(virDomainDefPtr def, virQEMUCapsPtr qemuCaps) { - if (def->os.arch != VIR_ARCH_ARMV7L && + if (def->os.arch != VIR_ARCH_ARMV6L && + def->os.arch != VIR_ARCH_ARMV7L && def->os.arch != VIR_ARCH_AARCH64) return; @@ -2367,7 +2368,8 @@ static bool qemuDomainSupportsPCI(virDomainDefPtr def, virQEMUCapsPtr qemuCaps) { - if ((def->os.arch != VIR_ARCH_ARMV7L) && + if ((def->os.arch != VIR_ARCH_ARMV6L) && + (def->os.arch != VIR_ARCH_ARMV7L) && (def->os.arch != VIR_ARCH_AARCH64) && !ARCH_IS_RISCV(def->os.arch)) return true; diff --git a/tests/capabilityschemadata/caps-qemu-kvm.xml b/tests/capabilityschemadata/caps-qemu-kvm.xml index 1aa98d140f..01cebcab16 100644 --- a/tests/capabilityschemadata/caps-qemu-kvm.xml +++ b/tests/capabilityschemadata/caps-qemu-kvm.xml @@ -81,6 +81,16 @@ </features> </guest> +<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> + <guest> <os_type>hvm</os_type> <arch name='armv7l'> diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c index 0d3e9fc7e6..3f7d3b107d 100644 --- a/tests/testutilsqemu.c +++ b/tests/testutilsqemu.c @@ -392,7 +392,39 @@ static int testQemuAddS390Guest(virCapsPtr caps) return -1; } -static int testQemuAddArmGuest(virCapsPtr caps) +static int testQemuAddArm6Guest(virCapsPtr caps) +{ + static const char *machines[] = { "versatilepb" }; + virCapsGuestMachinePtr *capsmachines = NULL; + virCapsGuestPtr guest; + + capsmachines = virCapabilitiesAllocMachines(machines, + ARRAY_CARDINALITY(machines)); + if (!capsmachines) + goto error; + + guest = virCapabilitiesAddGuest(caps, VIR_DOMAIN_OSTYPE_HVM, VIR_ARCH_ARMV6L, + QEMUBinList[TEST_UTILS_QEMU_BIN_ARM], + NULL, + ARRAY_CARDINALITY(machines), + capsmachines); + if (!guest) + goto error; + + if (!virCapabilitiesAddGuestDomain(guest, VIR_DOMAIN_VIRT_QEMU, NULL, NULL, 0, NULL)) + goto error; + if (!virCapabilitiesAddGuestDomain(guest, VIR_DOMAIN_VIRT_KVM, + NULL, NULL, 0, NULL)) + goto error; + + return 0; + + error: + virCapabilitiesFreeMachines(capsmachines, ARRAY_CARDINALITY(machines)); + return -1; +} + +static int testQemuAddArm7Guest(virCapsPtr caps) { static const char *machines[] = { "vexpress-a9", "vexpress-a15", @@ -426,6 +458,7 @@ static int testQemuAddArmGuest(virCapsPtr caps) return -1; } + static int testQemuAddAARCH64Guest(virCapsPtr caps) { static const char *machines[] = { "virt"}; @@ -514,7 +547,10 @@ virCapsPtr testQemuCapsInit(void) if (testQemuAddS390Guest(caps)) goto cleanup; - if (testQemuAddArmGuest(caps)) + if (testQemuAddArm6Guest(caps)) + goto cleanup; + + if (testQemuAddArm7Guest(caps)) goto cleanup; if (testQemuAddAARCH64Guest(caps)) -- 2.19.2
On Sun, 2018-11-25 at 21:09 +0000, infos@nafets.de wrote:
From: Stefan Schallenberg <nafets227@users.noreply.github.com>
Support for armv6l qemu guests has been added. Tested with arm1176 CPU on x86.
What OS did you run inside the guest? I would like to give this a try myself.
Signed-off-by: Stefan Schallenberg <infos at nafets.de>
The S-o-b should contain a proper, non-obfuscated email address. [...]
+ <change> + <summary> + Add armv6l Support as guest + </summary> + <description> + Support for armv6l qemu guests has been added. + Tested with arm1176 CPU on x86. + </description> + </change>
Changes to the release notes should be in a separate commit. I would also put this in the "New features" section, and tweak it slightly for style so that it looks along the lines of <change> <summary> qemu: Add support for ARMv6l guests </summary> </change> The change is pretty self-explanatory, and how the feature was tested is good information to have in the commit message but not really release notes material :) [...]
+++ b/docs/schemas/basictypes.rng @@ -407,6 +407,7 @@ <value>aarch64</value> <value>alpha</value> <value>armv7l</value> + <value>armv6l</value>
Entries are sorted, so armv6l should go *before* armv7l. [...]
@@ -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. 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. [...]
@@ -4177,6 +4177,7 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
/* GIC capabilities, eg. available GIC versions */ if ((qemuCaps->arch == VIR_ARCH_AARCH64 || + qemuCaps->arch == VIR_ARCH_ARMV6L || qemuCaps->arch == VIR_ARCH_ARMV7L) &&
This, and many similar conditions, could basically be rewritten as if (ARCH_IS_ARM(...)) were it not for the fact that ARCH_IS_ARM() also includes ARMv7b. I wonder if it would make sense to have a few more fine-grained macros such as ARCH_IS_ARM64() / ARCH_IS_ARM32() ARCH_IS_ARMLE() / ARCH_IS_ARMBE() and whether we should introduce VIR_ARCH_AARCH64BE / VIR_ARCH_ARMV6B to cover all bases - at least as far as I know, all CPUs dating back to ARMv6 can work in both Little Endian and Big Endian mode, so limiting the latter to ARMv7 only seems wrong. This is just me thinking out loud about the bigger picture, though: for the purpose of your patch, the way you're changing the various conditions is just fine. [...]
--- a/tests/capabilityschemadata/caps-qemu-kvm.xml +++ b/tests/capabilityschemadata/caps-qemu-kvm.xml @@ -81,6 +81,16 @@ </features> </guest>
+<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? -- Andrea Bolognani / Red Hat / Virtualization
> -----Ursprüngliche Nachricht-----
> Von: Andrea Bolognani <abologna@redhat.com>
> Gesendet: Montag, 26. November 2018 17:47
> An: infos@nafets.de; libvir-list@redhat.com
> Cc: Stefan Schallenberg <nafets227@github.github.io>
> Betreff: Re: [libvirt] [PATCH 1/2] Add armv6l Support as guest
>
> On Sun, 2018-11-25 at 21:09 +0000, infos@nafets.de wrote:
> > From: Stefan Schallenberg <nafets227@users.noreply.github.com>
> >
> > Support for armv6l qemu guests has been added.
> > Tested with arm1176 CPU on x86.
>
> 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 :=)
>
> > Signed-off-by: Stefan Schallenberg <infos at nafets.de>
>
> The S-o-b should contain a proper, non-obfuscated email address.
>
Will follow up on this and other details with an updated patch later.
[...]
> [...]
> > @@ -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.
> 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?
[...]
> > --- a/tests/capabilityschemadata/caps-qemu-kvm.xml
> > +++ b/tests/capabilityschemadata/caps-qemu-kvm.xml
> > @@ -81,6 +81,16 @@
> > </features>
> > </guest>
> >
> > +<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?
On Tue, 2018-11-27 at 20:37 +0100, infos@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.14.... - dtb https://github.com/dhruvvyas90/qemu-rpi-kernel/blob/master/versatile-pb.dtb?... 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
On Wed, 2018-11-28 at 13:25 +0100, Andrea Bolognani wrote:
On Tue, 2018-11-27 at 20:37 +0100, infos@nafets.de wrote:
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.... - dtb https://github.com/dhruvvyas90/qemu-rpi-kernel/blob/master/versatile-pb.dtb?... 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"
Okay, I'll give it a try.
I tried the above but using the latest Raspbian Stretch Lite image instead of Arch: the guest comes up with no issues and offers serial console access, so that part works nicely. However, I notice that you are using '--network none' and so of course there is no network connectivity inside the guest. My own attempts at fixing this were unsuccessful, in that I can get a PCI device such as rtl8139 or even virtio-net-pci to be detected by the guest, but the corresponding drivers are not included in the kernel downloaded from the GitHub repository linked above; the versatilepb board's own integrated network device (smc91c111), on the other hand, seems not to support instantiation via -device and is thus not usable without adding hacks to libvirt. Did you manage to get network functionality working some other way? Since you already need a custom kernel to boot the image with QEMU, and you also use an approximation of the actual hardware rather than a faithful reproduction, I think it would make sense to go one step further and include VirtIO drivers in the kernel image. -- Andrea Bolognani / Red Hat / Virtualization
[...]
I tried the above but using the latest Raspbian Stretch Lite image instead of Arch: the guest comes up with no issues and offers serial console access, so that part works nicely. Yes, this might better fit as the kernel is based on Debian (=Raspbian) and arch uses a complete Different kernel. However I want to use Arch for different reasons, so I am going to try how to get It working better.
However, I notice that you are using '--network none' and so of course there is no network connectivity inside the guest. My own attempts at fixing this were unsuccessful, in that I can get a PCI device such as rtl8139 or even virtio-net-pci to be detected by the guest, but the corresponding drivers are not included in the kernel downloaded from the GitHub repository linked above; the versatilepb board's own integrated network device (smc91c111), on the other hand, seems not to support instantiation via -device and is thus not usable without adding hacks to libvirt. Did you manage to get network functionality working some other way? No, I did not get network going yet. I saw the same two options, either hack libvirt to be able to deal with default NIC or add virtio support to the kernel.
Since you already need a custom kernel to boot the image with QEMU, and you also use an approximation of the actual hardware rather than a faithful reproduction, I think it would make sense to go one step further and include VirtIO drivers in the kernel image. Ideal solution would be an arch package with a kernel that supports both smc91c111 and virtio to be flexible. Lets see if I get it working, but being able to work on it only in my spare time it will take a while. However the patches are the basic to keep on working on a custom kernel :=)
Stefan Schallenberg
On Thu, 2018-11-29 at 21:12 +0100, infos@nafets.de wrote:
However, I notice that you are using '--network none' and so of course there is no network connectivity inside the guest. My own attempts at fixing this were unsuccessful, in that I can get a PCI device such as rtl8139 or even virtio-net-pci to be detected by the guest, but the corresponding drivers are not included in the kernel downloaded from the GitHub repository linked above; the versatilepb board's own integrated network device (smc91c111), on the other hand, seems not to support instantiation via -device and is thus not usable without adding hacks to libvirt. Did you manage to get network functionality working some other way?
No, I did not get network going yet. I saw the same two options, either hack libvirt to be able to deal with default NIC or add virtio support to the kernel.
I gave the second option a try and confirmed it works; based on those results, I've opened https://github.com/dhruvvyas90/qemu-rpi-kernel/pull/63 Let's see whether or not the maintainer likes the approach :) In the meantime, I have tweaked your patches as agreed upon and pushed them. Congratulations on your first contribution to libvirt! -- Andrea Bolognani / Red Hat / Virtualization
From: Stefan Schallenberg <nafets227@users.noreply.github.com> Signed-off-by: Stefan Schallenberg <infos at nafets.de> --- src/qemu/qemu_domain.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index acf351f878..c8157b6888 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -3267,6 +3267,15 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def, addDefaultMemballoon = false; if (qemuDomainIsARMVirt(def)) addPCIeRoot = virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_GPEX); + + if (!ARCH_IS_RISCV(def->os.arch) || + STREQ(def->os.machine, "versatilepb")) + addPCIRoot = true; + + if (qemuDomainIsARMVirt(def) && + virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_GPEX)) + addPCIRoot = true; + break; case VIR_ARCH_PPC64: -- 2.19.2
On Sun, 2018-11-25 at 21:09 +0000, infos@nafets.de wrote: [...]
@@ -3267,6 +3267,15 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def, addDefaultMemballoon = false; if (qemuDomainIsARMVirt(def)) addPCIeRoot = virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_GPEX); + + if (!ARCH_IS_RISCV(def->os.arch) || + STREQ(def->os.machine, "versatilepb")) + addPCIRoot = true; + + if (qemuDomainIsARMVirt(def) && + virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_GPEX)) + addPCIRoot = true; +
This is not indented properly; more importantly, the logic doesn't make a whole lot of sense to me. You're checking whether the arch is RISC-V in a case that you'll only hit for ARM architectures, and (with the second if) causing aarch64 virt guests to have both a pcie-root and a pci-root, which helpfully breaks the test suite. Please ensure 'make check' and 'make syntax-check' pass after each one of your patches before posting. -- Andrea Bolognani / Red Hat / Virtualization
-----Ursprüngliche Nachricht----- Von: Andrea Bolognani <abologna@redhat.com> Gesendet: Montag, 26. November 2018 17:50 An: infos@nafets.de; libvir-list@redhat.com Cc: Stefan Schallenberg <nafets227@github.github.io> Betreff: Re: [libvirt] [PATCH 2/2] qemu: Add Default PCI Device for arm guests
On Sun, 2018-11-25 at 21:09 +0000, infos@nafets.de wrote: [...]
@@ -3267,6 +3267,15 @@ qemuDomainDefAddDefaultDevices(virDomainDefPtr def, addDefaultMemballoon = false; if (qemuDomainIsARMVirt(def)) addPCIeRoot = virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_GPEX); + + if (!ARCH_IS_RISCV(def->os.arch) || + STREQ(def->os.machine, "versatilepb")) + addPCIRoot = true; + + if (qemuDomainIsARMVirt(def) && + virQEMUCapsGet(qemuCaps, QEMU_CAPS_OBJECT_GPEX)) + addPCIRoot = true; +
This is not indented properly; more importantly, the logic doesn't make a whole lot of sense to me.
You're checking whether the arch is RISC-V in a case that you'll only hit for ARM architectures, and (with the second if) causing aarch64 virt guests to have both a pcie-root and a pci-root, which helpfully breaks the test suite. The Source code is copied from qemuDomainSupportsPCI that is not accessible at this point. Any good suggestions how to either make qemuDomainSupportsPCI available and call it or have a better condition to check whether this machine has a default PCI?
Please ensure 'make check' and 'make syntax-check' pass after each one of your patches before posting.
-- Andrea Bolognani / Red Hat / Virtualization
participants (2)
-
Andrea Bolognani -
infos＠nafets.de