On 06/24/2017 10:07 PM, Andrea Bolognani wrote: > On Sat, 2017-06-24 at 16:07 +0200, Christoffer Dall wrote: >>> The way I see it, the bug is about libvirt being unable to >>> launch guests which use the <console><log> feature, and with >>> that in mind your patch is correct but doesn't solve the >>> issue, because even thought that specific error is gone you >>> immediately run into a different one and your guest is still >>> unable to start. >> >> I didn't experience this, it was actually working on my end. I wonder >> if it's related to the QEMU version, where I seem to remember we >> changed what some serial options turned into. But I for sure did not >> see "-device isa-serial..." on the command line, so maybe not. > > That's very different from the behavior I'm seeing, and I > can't figure out why that would be the case. That's why > having your QEMU command line would be very useful. > > As for differences in QEMU binaries, there might be some > capability that I haven't considered and influences the > generated command line. I'll look into that. > >> In any case, I'll reproduce again when I'm back and send you the details. > > Sounds good to me. > >>> Just to be clear: I'm not against this patch, we definitely >>> want to fix virQEMUCapsSupportsChardev(). What gave me pause >>> is simply the fact that you seemed to claim it made the >>> <console><log> feature usable, which I'm still unconvinced >>> is actually the case. >> >> Oh, I didn't intend to claim that. I intended to claim that >> >> <serial type='pty'> >> <log file='/tmp/testlogfile.log' append='off'/> >> <target port='0'/> >> >> now works. > > Well, that's the same thing, really :) > > Adding <serial type='pty'/> will automatically add > <console type='pty'/>, so if one works the other should > work as well, since they translate to a single QEMU option > at the end of the day. > >> I'm not sure where I claimed more beyond that, can you >> point me to specifics (this patch or the bug report, etc.) and I'll be >> happy to correct that? > > https://bugs.linaro.org/show_bug.cgi?id=2777#c36 > > Also, twice in the message I'm replying to ;) > >> At this point I'm a little confused about how to proceed here. Would >> you like further evidence of an environment that reproduces the issue >> with console and the isa bus, with additional logic added to this >> patch to fix that, or should we get this patch merged and fix the >> other issue separately? > > We can merge the patch without further changes to it, as > it fixes part of the issues that prevent the feature to work. > > Actually, I just added > > Reviewed-by: Andrea Bolognani <abologna@xxxxxxxxxx> > > and pushed it :) It may fix part of the issue but it likely breaks all existing aarch64 -M virt libvirt VMs. My VM created by virt-manager has: <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> And after this patch fails with: error: Failed to start domain fedora25-aarch64 error: internal error: process exited while connecting to monitor: 2017-06-26T13:55:34.726293Z qemu-system-aarch64: -chardev pty,id=charserial0: char device redirected to /dev/pts/5 (label charserial0) 2017-06-26T13:55:34.782121Z qemu-system-aarch64: -device isa-serial,chardev=charserial0,id=serial0: No 'ISA' bus found for device 'isa-serial' There's a few things going on here: - Internally libvirt thinks that by default <serial> is isa-serial - For arm qemu though it's actually a pl011. This is a platform device and as such there isn't any current way to use -chardev with it AFAIK. - However -chardev will work for pci-serial device, which is <serial><target type='serial'/> So for one, we should change SupportsChardev to also check the devices target type. The test suite likely needs to be extended to add QEMU_CAPS_CHARDEV for all arm/aarch64 test cases, to demonstrate the change. And describe the existing logic by adding a TARGET_TYPE_PL011 which is filled in as the default for arm/aarch64, and then we can key off that in the code. After that I think the options are either: 1) Openstack/other tools specifies target type='pci' for PCIe machvirt, to make <log> work 2) Change the libvirt serial default to target type=pci for PCIe machvirt. Not sure if they are operationally equivalent for all cases we care about though. Maybe we could make some kind of adaptive default like 'if PCIe machvirt && serial device has <log> specified (or other features) then default target type=pci', but maybe that's too magic Would also be nice to have the libvirt output XML always list the serial target type which would clear up some of this confusion, but might cause migration XML compat issues for other archs In the interim though I think this patch should be reverted. Thanks, Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
