Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device

From: Cole Robinson <crobinso@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	QEMU <qemu-devel@nongnu.org>,
	"Dave Anderson" <anderson@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@gmail.com>,
	"Martin Kletzander" <mkletzan@redhat.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Laszlo Ersek" <lersek@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device
Date: Tue, 17 Apr 2018 18:31:57 -0400	[thread overview]
Message-ID: <f822d32f-5d0f-aa42-95a8-46afd4923d45@redhat.com> (raw)
In-Reply-To: <20180417211126.GD29865@localhost.localdomain>

On 04/17/2018 05:11 PM, Eduardo Habkost wrote:
> On Tue, Apr 17, 2018 at 03:12:03PM -0400, Cole Robinson wrote:
> [...]
>> Reviving this... did any follow up changes happen?
>>
>> Marc-André patched virt-manager a few months back to enable -device
>> vmcoreinfo for new VMs:
>>
>> https://www.redhat.com/archives/virt-tools-list/2018-February/msg00020.html
>>
>> And I see there's at least a bug tracking adding this to openstack for
>> new VMs:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1555276
>>
>> If this feature doesn't really have any downsides, it would be nice to
>> get this tied to new machine types. Saves a lot of churn for higher
>> levels of the stack
> 
> I understand this would be nice to have considering the existing
> stacks, but at the same time I would like the rest of the
> stack(s) to really try to not depend on QEMU machine-types to
> define policy/defaults.
> 
> Every feature that is hidden behind an opaque machine-type name
> and not visible in the domain XML and QEMU command-line increases
> the risk of migration and compatibility bugs.
> 

What exactly is the migration compatibility issue with turning on the
equivalent of -device vmcoreinfo for -M *-2.13+ ? Possibly prevents
backwards migration to older qemu but is that even a goal?

> This was being discussed in a mail thread at:
> https://www.mail-archive.com/ovirt-devel@redhat.com/msg01196.html
> 
> Quoting Daniel, on that thread:
> 
> ] Another case is the pvpanic device - while in theory that could
> ] have been enabled by default for all guests, by QEMU or a config
> ] generator library, doing so is not useful on its own. The hard
> ] bit of the work is adding code to the mgmt app to choose the
> ] action for when pvpanic triggers, and code to handle the results
> ] of that action.
> 
> From that comment, I understand that simply making QEMU create a
> pvpanic device by default on pc-2.13+ won't be useful at all?
> 

This qemu-devel thread was about -device vmcoreinfo though, not pvpanic.
vmcoreinfo doesn't need anything else to work AFAICT and shouldn't need
any explicit config, heck it doesn't even have any -device properties.

Like Dan says pvpanic isn't a 'just works' thing, and I know for windows
VMs it shows up in device manager which has considerations for things
like SVVP. I think vmcoreinfo doesn't have the same impact

There are some guest visible things that we have turned on for new
machine types in the past, pveoi and x2apic comes to mind.

Thanks,
Cole