Re: [libvirt] [PATCH 2/2] hw/vfio/display: add ramfb support
On Fri, Sep 14, 2018 at 12:50:09PM +0200, Gerd Hoffmann wrote:
Hi,
> > Also libvirt manages hotpluggability per device *class*, not per device
> > *instance*. So a device being hotpluggable or not depending on some
> > device property is a problem for libvirt ...
> >
> > I'm open to suggestions how to handle this better, as long as the
> > libvirt people are on board with the approach.
>
> Ok, so we need a new class to handle making a device non-hotpluggable,
> but I'm still not sure whether we should make:
>
> -device vfio-pci-ramfb
>
> or
>
> -device vfio-pci-nohotplug,ramfb=on
>
> Where ramfb would be a property only available on the nohotplug class
> variant.
I'm fine with the latter.
> The latter seems to provide a lot more flexibility, but which
> is more practical for libvirt?
Any comment from the libvirt camp?
We had a discussion about this a few months ago [1] where we spoke about
-device vfio-pci-ramfb. However, as Alex has pointed out, the latter proposal
gives us more flexibility in terms of introduction of other device properties
which are unrelated to ramfb but still might require non-hotpluggable device.
Either way, libvirt needs a capability to test whether we should favour this
new device over plain vfio-pci if an mdev with display='on' is required.
What about new device properties (specifically mdev)? In the discussion below,
Gerd noted that apart from the ramfb stuff and the fact that one can be
hotplugged while the latter can not, these are identical (option-wise), is that
to stay, IOW are we going to keep these two device classes in sync when
introducing new vfio-pci device options or are these going to divert more? Is
it even possible? What I mean by that is that I'd like to avoid is a situation
where there are 2 disjunct sets of options which could potentially lead to
problems in decision making in libvirt and we don't like making decisions.
Anyhow, I don't feel like any of the proposals has a strong
advantage/disadvantage in usage for libvirt, both will require a capability and
both would be special cased in our cmdline code depending on the 'display'
attribute. Luckily, we don't have mdev migration yet, so it's good we don't
have to worry about that at this point yet.
[1] https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg03430.html
Erik