[libvirt] [PATCH 1/2] conf: add crash to hyperv features

[Jiri Denemark]

On Wed, Nov 11, 2015 at 12:09:33 +0300, Denis V. Lunev wrote:
> On 11/11/2015 11:57 AM, Dmitry Andreev wrote:
> > Adding colleague to CC
> >
> > On 11.11.2015 11:34, Jiri Denemark wrote:
...
> >> Yeah, this what I was thinking about. After all, we already do something
> >> similar on Power. The guest panic notification is an integral part of
> >> the platform itself so there's no device we need to add. To reflect this
> >> in our domain XMLs, we just always add
> >>
> >>      <device>
> >>        <panic/>
> >>      </device>
> >>
> >> Thus using <panic> element for hv_crash seems like the best approach to
> >> me. We'd have just one place for configuring all kinds of guest crash
> >> notifications. The question is what the XML should look like. The form
> >> suggested by Peter looks good, but then we should probably add the model
> >> attribute to all panic devices to make it consistent. So a theoretical
> >> XML using all currently supported panic "devices" would be:
> >>
> >>      <device>
> >>        <panic model='hyperv'/>  <!-- hv_crash -->
> >>        <panic model='isa'/>     <!-- pvpanic -->
> >>        <panic model='pseries'/> <!-- Power -->
> >>      </device>
> >>
> >> 'pseries' model would only be allowed on Power, while the others would
> >> only be allowed on x86. We'd need to automatically add model='...' to
> >> existing device, but it should be pretty easy. Any older libvirt would
> >> just ignore the attribute completely and a new libvirt would add
> >> model='isa' on x86 and model='pseries' on Power.
> >>
> >> Jirka
> >>
> QEMU accepts this option through HyperV set of CPU options.
...
> Thus your proposal means that in this case we will have to add
> this option to CPU part of the command line from devices
> part.
> 
> Is this correct?

Yes.

> And, finally, 'no', this is not a device from QEMU perspective
> of view.

I know. It's not a device on Power either. In libvirt we try to make
things consistent across various platforms and hypervisors. We were not
always successful in this usually because our original design of some
features were not future proof enough. But we can easily maintain
consistency in this case, we already have a panic "device" and hv_crash
can be easily mapped into it.

If sticking with QEMU way of configuring various features was our goal,
all other hyperv features would rather be enabled within <cpu> element.
But we enable them differently in domain XML because it just didn't fit
very well in libvirt's <cpu> element.

Thus using device/panic for hv_crash even if it's not a device is IMHO
better because it keeps all crash notification config consistent. Anyone
wishing to know whether guest crash events notifications are enabled for
a domain can just look for device/panic element without thinking about
all possible implementations which are hidden inside libvirt anyway.

Jirka