On Sat, Jun 24, 2017 at 3:37 PM, Andrea Bolognani <abologna@xxxxxxxxxx> wrote:
> On Fri, 2017-06-23 at 18:32 +0200, Christoffer Dall wrote:
>> > You mention in [1] that applying this patch and using a
>> > recent QEMU fixes the problem for you, however I can't
>> > say the same: I still get
>> >
>> > -device isa-serial,chardev=charserial0,id=serial0:
>> > No 'ISA' bus found for device 'isa-serial'
>>
>> Well that's not the bug reported in 2777. If you try to create an ISA
>> bus or configure your domain with an ISA bus on AArch64 your are bound
>> to fail, because we never had, and we never will have, support for an
>> ISA bus on AArch64.
>
> Sure, I'm aware of that.
>
>> To verify what this patch changes, you can use the test xml file
>> listed in [1] as well:
>>
>> <domain type='kvm'>
>> <name>testlogfile</name>
>> <memory unit='KiB'>524288</memory>
>> <os>
>> <type arch='aarch64' machine='virt-2.7'>hvm</type>
>> </os>
>> <devices>
>> <serial type='pty'>
>> <log file='/tmp/testlogfile.log' append='off'/>
>> <target port='0'/>
>> </serial>
>> </devices>
>> </domain>
>>
>> Or any working domain configuration where you add <log file='...' />
>> to the domain definition.
>
> In both cases, I get the error reported in my previous
> message.
>
> You didn't really answer my question, though: can *you*
> start such a guest succesfully using a patched libvirt?
Yes, I can. But since I now left for holiday and I turned off my
desktop at home, I cannot immediately dig out the details of a config
domain xml file etc.
Riku, did you have a chance to reproduce the issue with my patch as well?
> And if so, what is the corresponding QEMU command line?
>
I'll be happy to dig this out for you when I return though.
>> It may be that we have an additional bug in libvirt that it under some
>> circumstances tries to create an ISA bus with an AArch64 VM, but I
>> don't see that being related to the patch above?
>
> It's not.
>
>> Note that the submitted patch fixes virQEMUCapsSupportsChardev, which
>> should be independent from any ISA bus fixes in libvirt, but given my
>> very limited experience with libvirt, I may be wrong here.
>
> No, you're correct.
>
>> In summary, if your test setup goes from "error: unsupported
>> configuration: logfile not supported in this QEMU binary" to "-device
>> isa-serial,chardev=charserial0,id=serial0: No 'ISA' bus found for
>> device 'isa-serial'" then I'd argue that my patch solves the first
>> issue.
>
> 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.
In any case, I'll reproduce again when I'm back and send you the details.
>
> 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. 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?
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?
I'll try to look at reproducing the isa bus thing and seeing if I can
come up with a fix when I'm back, unless someone beats me to it, which
is not unlikely given the time it takes me to dig through libvirt
abstraction layers.
Thanks,
-Christoffer
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
