[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-6.0] accel: Wire accel to /machine
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH for-6.0] accel: Wire accel to /machine |
Date: |
Mon, 7 Dec 2020 17:44:19 +0000 |
User-agent: |
Mutt/1.14.6 (2020-07-11) |
On Mon, Dec 07, 2020 at 11:46:22AM +0300, Roman Bolshakov wrote:
> There's no generic way to query current accel and its properties via QOM
> because there's no link between an accel and current machine.
>
> The change adds the link, i.e. if HVF is enabled the following will be
> available in QOM:
>
> (qemu) qom-get /machine/accel type
> "hvf-accel"
>
> Suggested-by: Markus Armbruster <armbru@redhat.com>
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> ---
>
> Hi,
>
> this is a follow up patch that deprecates earlier series [1].
>
> An outstanding issue is whether management applications can rely on the
> value of /machine/accel/type and output of qom-list-types command [2][3]
> to get current and present accels?
>
> i.e. would it be ok if libvirt assumes that everything up to the first
> dash in the accel type is the name of the accel (as specified via -M
> accel=ACCEL flag) when it performs QEMU probing?
Hmm, I think it is not nice - we shouldn't have to parse the
accel type names - IMHO typenames should be considered arbitrary
opaque strings, even if they'll not be expected to change.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|