Re: [libvirt] [PATCH v3 0/7] extend virsh domstate to show additional information
So, what's my course of action here?
Daniel P. Berrangé <berrange(a)redhat.com> [2019-04-04, 11:32AM +0100]:
I guess the obvious extra thing to want to report is CPU registers,
since
the crash info is largely containing register and/or memory address info.
Sounds reasonable if we go with the virDomainGetCPUState API.
QEMU has "info registers" but no QMP variant of it at this
time.
Can I still implement my stuff with the proposed API without the actual
register information until this is implemented in QEMU? Meaning, just
reporting the relevant register information from the panic event. While
it is nice to have the full feature set available, implementing the QMP
command for this would be a bit out of the scope of this proposal.
With this in mind though, the proposed API is not satisfactory.
Specifically
the field
# define VIR_DOMAIN_STATE_PARAM_TYPE "info_type"
As that assumes an either / or reporting need. If we added register
info, then we would potentially need to report crash info *and* register
info at the same time.
I think this is easy to solve though - just delete the
VIR_DOMAIN_STATE_PARAM_TYPE field as it is redundant. Apps can just
look at whatever named parameters exist & use those they care about.
Sure, the type parameter was basically an easy way for the client to
figure out what data it has retrieved, especially when the parameter
space was that large with all the (potential) different states.
The more critical thing is that in an SMP system, we'll need to
report
registers per CPU, but this API is a per-VM level reporting.
This is something we do with virDomainGetCPUStats().
So I think we need a design closer to that API, and perhaps call it
"virDomainGetCPUState" / virsh domcpustate
Any hint how this API actually should look like? Exactly like
virDomainGetCPUStats with the per-CPU-dance or should we just report
back all available information?
In the case of a panicked domain, how should we report the relevant
information (crashed core/reason)?
Regards,
Daniel
Thanks for the discussion and suggestions.
Bjoern
--
IBM Systems
Linux on Z & Virtualization Development
--------------------------------------------------
IBM Deutschland Research & Development GmbH
Schönaicher Str. 220, 71032 Böblingen
Phone: +49 7031 16 1819
--------------------------------------------------
Vorsitzende des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
Attachments:
- signature.asc (application/pgp-signature — 902 bytes)