All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	libvir-list@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/2] hw/vfio/display: add ramfb support
Date: Wed, 12 Sep 2018 11:13:54 -0600	[thread overview]
Message-ID: <20180912111354.4163d9ce@t450s.home> (raw)
In-Reply-To: <20180911043843.egzz6pqe5ouzju3g@sirius.home.kraxel.org>

On Tue, 11 Sep 2018 06:38:43 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

>   Hi,
> 
> > >      type_register_static(&vfio_pci_dev_info);
> > > +    type_register_static(&vfio_pci_ramfb_dev_info);  
> 
> > My concern here is still all of the extra tooling that needs to be
> > added to management layers above QEMU for this device that exists only
> > because we can't hotplug the primary display in QEMU.  What happens when
> > we can hotplug the primary display?  
> 
> Ramfb uses fw_cfg, and fw_cfg files can't be added or removed at
> runtime, the interface simply isn't designed for that.
> 
> > Aren't disabling hotplug of a
> > vfio-pci device and supporting ramfb two separate things?  I think
> > we're leaking current implementation issues out to the device options
> > when really we'd rather have a "ramfb" (or perhaps "console") option on
> > the vfio-pci device and the hotplug capability determined automatically
> > and available through introspection of the device.  
> 
> Well, I don't think libvirt will have too much trouble handling this.
> We have two variants (with and without vga compatibility) of other
> devices: qxl-vga and qxl, virtio-vga and virtio-gpu-pci.  libvirt copes
> just fine and picks the right one (I think depending on video model
> 'primary' property).
> 
> 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.  The latter seems to provide a lot more flexibility, but which
is more practical for libvirt?  Thanks,

Alex

  reply	other threads:[~2018-09-12 17:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10  6:43 [Qemu-devel] [PATCH 0/2] hw/vfio/display: add ramfb support Gerd Hoffmann
2018-09-10  6:43 ` [Qemu-devel] [PATCH 1/2] stubs: add ramfb Gerd Hoffmann
2018-09-10  6:43 ` [Qemu-devel] [PATCH 2/2] hw/vfio/display: add ramfb support Gerd Hoffmann
2018-09-10 18:54   ` Alex Williamson
2018-09-11  4:38     ` Gerd Hoffmann
2018-09-12 17:13       ` Alex Williamson [this message]
2018-09-14 10:50         ` Gerd Hoffmann
2018-09-14 14:19           ` [Qemu-devel] [libvirt] " Erik Skultety
2018-09-14 15:16             ` Alex Williamson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180912111354.4163d9ce@t450s.home \
    --to=alex.williamson@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.