From: Alex Williamson <alex.williamson@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: kvm@vger.kernel.org, Erik Skultety <eskultet@redhat.com>,
libvirt <libvir-list@redhat.com>,
Tina Zhang <tina.zhang@intel.com>,
kwankhede@nvidia.com, intel-gvt-dev@lists.freedesktop.org
Subject: Re: [libvirt] [PATCH 0/3] sample: vfio mdev display devices.
Date: Tue, 24 Apr 2018 11:35:50 -0600 [thread overview]
Message-ID: <20180424113550.367b83ce@w520.home> (raw)
In-Reply-To: <20180424071737.nf4zin5pytnjfgsc@sirius.home.kraxel.org>
On Tue, 24 Apr 2018 09:17:37 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:
> Hi,
>
> > Here's another proposal that's really growing on me:
> >
> > * Fix the vendor drivers! Allow devices to be opened and probed
> > without these external dependencies.
>
> Hmm. If you try use gvt with tcg then, wouldn't qemu think "device
> probed ok, all green" then even though that isn't the case?
Well, is there a way to make it work with tcg? That would be the best
solution. Perhaps KVM could be handled as an accelerator rather than a
required component. I don't really understand how the page tracking
interface is used and why it's not required by NVIDIA if it's so
fundamental to GVT-g. Otherwise, are there other points at which the
device could refuse to be enabled, for instance what if the write to
enable bus-master in the PCI command register returned an error if the
device isn't fully configured. Paolo had suggested offline that maybe
there could be a read-only mode of the device that allows probing. I
think that would be a fair bit of work and complexity to support, but
I'm open to those sorts of ideas. I can't be sure the NVIDIA
requirement isn't purely for accounting purposes within their own
proprietary userspace manager, without any real technical requirement.
Hoping Intel and NVIDIA can comment on these so we really understand
why these are in place before we bend over backwards for a secondary API
interface. Thanks,
Alex
next prev parent reply other threads:[~2018-04-24 17:35 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180409103513.8020-1-kraxel@redhat.com>
2018-04-09 10:35 ` [PATCH 1/3] sample: vfio mdev display - host device Gerd Hoffmann
2018-04-24 2:41 ` Alex Williamson
2018-04-24 6:29 ` Gerd Hoffmann
2018-04-09 10:35 ` [PATCH 2/3] sample: vfio mdev display - guest driver Gerd Hoffmann
2018-04-11 20:39 ` Bjorn Helgaas
2018-04-24 2:51 ` Alex Williamson
2018-04-25 21:03 ` Konrad Rzeszutek Wilk
2018-04-09 10:35 ` [PATCH 3/3] sample: vfio bochs vbe display (host device for bochs-drm) Gerd Hoffmann
2018-04-24 3:05 ` Alex Williamson
2018-04-18 18:31 ` [libvirt] [PATCH 0/3] sample: vfio mdev display devices Alex Williamson
2018-04-19 8:40 ` Gerd Hoffmann
2018-04-19 10:03 ` Zhenyu Wang
2018-04-19 14:20 ` Alex Williamson
2018-04-19 14:54 ` Paolo Bonzini
2018-04-23 21:40 ` Alex Williamson
2018-04-24 7:17 ` Gerd Hoffmann
2018-04-24 17:35 ` Alex Williamson [this message]
2018-04-25 9:49 ` Zhang, Tina
2018-04-24 19:50 ` Kirti Wankhede
2018-04-24 22:59 ` Alex Williamson
2018-04-25 15:30 ` Kirti Wankhede
2018-04-25 18:00 ` Alex Williamson
2018-04-25 19:52 ` Dr. David Alan Gilbert
2018-04-26 18:45 ` Kirti Wankhede
2018-04-26 18:55 ` Dr. David Alan Gilbert
2018-04-27 17:21 ` Alex Williamson
2018-05-03 18:58 ` [libvirt] Expose vfio device display/migration to libvirt and above, was " Alex Williamson
2018-05-04 7:49 ` Erik Skultety
2018-05-04 16:03 ` Alex Williamson
2018-05-07 6:25 ` Gerd Hoffmann
2018-07-20 4:56 ` Yuan, Hang
2018-08-08 7:43 ` Gerd Hoffmann
2018-05-10 11:00 ` Erik Skultety
2018-05-10 15:57 ` Alex Williamson
2018-05-04 9:16 ` Daniel P. Berrangé
2018-05-04 17:06 ` Alex Williamson
2018-05-07 6:15 ` Gerd Hoffmann
2018-05-04 8:39 ` [libvirt] " Erik Skultety
2018-04-26 3:44 ` Tian, Kevin
2018-04-26 6:14 ` Gerd Hoffmann
2018-04-26 15:44 ` 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=20180424113550.367b83ce@w520.home \
--to=alex.williamson@redhat.com \
--cc=eskultet@redhat.com \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=libvir-list@redhat.com \
--cc=tina.zhang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).