diff options
| author | Michal Privoznik <mprivozn@redhat.com> | 2024-06-24 10:52:49 +0200 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2024-07-03 18:41:26 +0200 |
| commit | f4e5f302b3361f13349b2a44378e7cf578a8e012 (patch) | |
| tree | 4d89412b7c92afe6795aef459c0ce0d8b9c57e47 /scripts/qapi/parser.py | |
| parent | ab5f4edf721fc0403d40a4db7e96808175157def (diff) | |
| download | qemu-f4e5f302b3361f13349b2a44378e7cf578a8e012.zip qemu-f4e5f302b3361f13349b2a44378e7cf578a8e012.tar.gz qemu-f4e5f302b3361f13349b2a44378e7cf578a8e012.tar.bz2 | |
i386/sev: Fallback to the default SEV device if none provided in sev_get_capabilities()
When management tools (e.g. libvirt) query QEMU capabilities,
they start QEMU with a minimalistic configuration and issue
various commands on monitor. One of the command issued is/might
be "query-sev-capabilities" to learn values like cbitpos or
reduced-phys-bits. But as of v9.0.0-1145-g16dcf200dc the monitor
command returns an error instead.
This creates a chicken-egg problem because in order to query
those aforementioned values QEMU needs to be started with a
'sev-guest' object. But to start QEMU with the values must be
known.
I think it's safe to assume that the default path ("/dev/sev")
provides the same data as user provided one. So fall back to it.
Fixes: 16dcf200dc951c1cde3e5b442457db5f690b8cf0
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Link: https://lore.kernel.org/r/157f93712c23818be193ce785f648f0060b33dee.1719218926.git.mprivozn@redhat.com
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'scripts/qapi/parser.py')
0 files changed, 0 insertions, 0 deletions