As of QEMU 2.1 we now have a new -cpu option, kvm=on|off which controls
whether we expose KVM as the hypervisor via the MSR hypervisor nodes.
The default is on. The off state is meant to hide kvm from standard
detection routines. This allows us to disable paravirtualization
detection in the guest
On Fri, 2014-08-15 at 10:38 -0400, Cole Robinson wrote:
> On 08/11/2014 05:54 PM, Alex Williamson wrote:
> > As of QEMU 2.1 we now have a new -cpu option, kvm=on|off which controls
> > whether we expose KVM as the hypervisor via the MSR hypervisor nodes.
> > The default is
is as follows:
...
Signed-off-by: Alex Williamson
---
If it's not obvious, this patch is derived from copying and modifying
the similar hyperv feature support. Hopefully I've found all the
right pieces.
docs/formatdomain.html.in | 21
do
On Tue, 2014-08-19 at 12:40 -0400, Cole Robinson wrote:
> On 08/15/2014 12:32 PM, Alex Williamson wrote:
> > QEMU 2.1 added support for the kvm=off option to the -cpu command,
> > allowing the KVM hypervisor signature to be hidden from the guest.
> > This enab
is as follows:
...
Signed-off-by: Alex Williamson
---
Hearing no further comments, here's v2:
- white space fix in docs/formatdomain.html.in
- s/virBufferAsprintf/virBufferAddLit/ in src/qemu/qemu_command.c
docs/formatdomain.html.in | 21
On Mon, 2015-06-22 at 14:44 -0400, Laine Stump wrote:
> This controller can be connected to any PCIe port, but not to a
> standard PCI port, which is the reason for the new connect type
> VIR_PCI_CONNECT_TYPE_PCIE_ONLY. pcie-switch provides 31 ports (slot=1
> to slot=31), which can only have pci co
On Mon, 2015-06-22 at 14:44 -0400, Laine Stump wrote:
> This is backed by the qemu device ioh3420.
> ---
> src/qemu/qemu_command.c | 20
>
> .../qemuxml2argv-pcie-root-port.args | 10 ++
> tests/qemuxml2argvtest.c
On Mon, 2015-06-22 at 14:44 -0400, Laine Stump wrote:
> This is backed by the qemu device xio3130-downstream. It can only be
> connected to a pcie-switch-upstream-port (x3130-upstream) on the
> upstream side.
> ---
> src/qemu/qemu_command.c | 15
> +++
On Tue, 2015-06-23 at 13:47 -0400, Laine Stump wrote:
> On 06/23/2015 11:23 AM, Alex Williamson wrote:
> > On Mon, 2015-06-22 at 14:44 -0400, Laine Stump wrote:
> >> diff --git a/src/conf/domain_addr.c b/src/conf/domain_addr.c
> >> index 4b5e81e..59da745 100644
> &
d VM
hosts and guests that use hugepage sizes and quantities are are
likely to be dynamically allocated as the VM is started.
In addition to the documentation provided within each script, a README
file is provided with overal instructions and summaries of the
individual scripts.
Signed-of
On Wed, 2015-06-24 at 12:57 -0600, Alex Williamson wrote:
> This patch provides scripts for hugepage allocation, as well as a bit
> of infrastructure and common hook config file that I hope may some day
> be enabled by default in libvirt. For now, we place the files in
> /usr/share a
On Tue, 2015-08-11 at 19:26 -0400, Laine Stump wrote:
> (Alex - I cc'ed you because I addressed a question or two your way down
> towards the bottom).
>
> On 08/11/2015 02:52 AM, Pavel Fedin wrote:
> > Hello!
> >
> >> The original patches to support pcie-root severely restricted what could
> >> p
On Wed, 2015-10-07 at 17:50 +0100, Daniel P. Berrange wrote:
> This looks for existance of /sys/firmware/acpi/tables/DMAR
> as a reasonable hint that the BIOS support an Intel IOMMU.
>
> This file is only present if enabled in the BIOS, so the
> check only does something if the BIOS is enabled but
}
>
> if (mlock) {
> -unsigned long long memKB;
> -
> -/* VFIO requires all of the guest's memory to be
> - * locked resident, plus some amount for IO
> - * space. Alex Williamson suggested adding 1GiB for IO
> - * spac
On Wed, 2015-11-04 at 16:54 +0100, Peter Krempa wrote:
> On Wed, Nov 04, 2015 at 08:43:34 -0700, Alex Williamson wrote:
> > On Wed, 2015-11-04 at 16:14 +0100, Peter Krempa wrote:
> > > For VFIO passthrough the guest memory including the device memory to be
> > > reside
On Thu, 2015-11-05 at 16:27 +0100, Peter Krempa wrote:
> On Wed, Nov 04, 2015 at 17:16:53 -0700, Alex Williamson wrote:
> > On Wed, 2015-11-04 at 16:54 +0100, Peter Krempa wrote:
> > > On Wed, Nov 04, 2015 at 08:43:34 -0700, Alex Williamson wrote:
> > > > On Wed, 20
On Fri, 2015-11-06 at 08:30 +0100, Peter Krempa wrote:
> On Thu, Nov 05, 2015 at 08:41:46 -0700, Alex Williamson wrote:
> > On Thu, 2015-11-05 at 16:27 +0100, Peter Krempa wrote:
> > > On Wed, Nov 04, 2015 at 17:16:53 -0700, Alex Williamson wrote:
>
> [...]
>
>
On Sat, 2015-11-14 at 14:06 +0530, Shivaprasad G Bhat wrote:
> Before unbind from stub driver libvirt should be sure the guest is not using
> the device anymore. The libvirt today waits for pci-stub driver alone in
> /proc/iommu.
> The same wait is needed for vfio devices too.
>
> Signed-off-by:
On Fri, 2015-11-20 at 12:26 +0530, Shivaprasad bhat wrote:
> On Fri, Nov 20, 2015 at 4:54 AM, Alex Williamson
> wrote:
> > On Sat, 2015-11-14 at 14:06 +0530, Shivaprasad G Bhat wrote:
> >> Before unbind from stub driver libvirt should be sure the guest is not
> >>
On Fri, 2015-11-20 at 11:33 -0500, Laine Stump wrote:
> On 11/14/2015 03:36 AM, Shivaprasad G Bhat wrote:
> > The reprobe needs to be called multiple times for vfio devices for each
> > device in the iommu group in future patch. So split the reprobe into a
> > new function. No functional change.
>
On Fri, 2015-11-20 at 12:24 -0500, Laine Stump wrote:
> On 11/20/2015 11:58 AM, Andrea Bolognani wrote:
> > On Fri, 2015-11-20 at 11:33 -0500, Laine Stump wrote:
> >> Seems safe, but is this really what we want to do? I haven't
> >> read/understood the remaining patches yet, but this makes it sound
On Wed, 2015-12-09 at 13:51 +0100, Andrea Bolognani wrote:
> On Wed, 2015-12-02 at 18:17 +0100, Andrea Bolognani wrote:
> > This series is my attempt at fixing
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1272300
> >
> [...]
> >
> > The problem being solved is that, when using VFIO, IOM
On Thu, 2015-12-10 at 09:06 +0100, Andrea Bolognani wrote:
> On Wed, 2015-12-09 at 08:09 -0700, Alex Williamson wrote:
> > > I was under the impression that what the current series
> > > does, eg. sharing devices in the same IOMMU group between
> > > the host driver a
> >
> >
> >
> >
> > But the error output when I boot one vm:
> >
> > [root@host3 VTS2.1-demo]# virsh create vtc.demo.xml
> > error: Failed to create domain from vtc.demo.xml
> > error: internal error: early end of file from monitor: po
On Tue, 15 Mar 2016 14:21:35 -0400
Laine Stump wrote:
> On 03/15/2016 01:00 PM, Daniel P. Berrange wrote:
> > On Mon, Mar 14, 2016 at 03:41:48PM -0400, Laine Stump wrote:
> >> Suggested by Alex Williamson.
> >>
> >> If you plan to assign a GPU to a virtual m
On Thu, 17 Mar 2016 17:32:08 +
"Daniel P. Berrange" wrote:
> On Tue, Mar 15, 2016 at 02:21:35PM -0400, Laine Stump wrote:
> > On 03/15/2016 01:00 PM, Daniel P. Berrange wrote:
> > >On Mon, Mar 14, 2016 at 03:41:48PM -0400, Laine Stump wrote:
> &
On Thu, 17 Mar 2016 17:59:53 +
"Daniel P. Berrange" wrote:
> On Thu, Mar 17, 2016 at 11:52:14AM -0600, Alex Williamson wrote:
> > On Thu, 17 Mar 2016 17:32:08 +
> > "Daniel P. Berrange" wrote:
> >
> > > On Tue, Mar 15, 2016 at 02:21
Sorry, apparently missed this reply previously
On Wed, 16 Mar 2016 11:19:38 +0100
Andrea Bolognani wrote:
> On Tue, 2016-03-15 at 13:31 -0600, Alex Williamson wrote:
> > So we have all sorts of driver issues that are sure to come and go over
> > time and all sorts of use
On Tue, 22 Mar 2016 12:54:12 +0100
Andrea Bolognani wrote:
> On Fri, 2016-03-18 at 11:03 -0600, Alex Williamson wrote:
> > > Anyway, after reading your explanation I'm wondering if we
> > > shouldn't always recommend a setup where devices that are going
> >
On Tue, 22 Mar 2016 19:04:31 +0100
Andrea Bolognani wrote:
> On Tue, 2016-03-22 at 09:04 -0600, Alex Williamson wrote:
> > > Could this be controlled by a kernel parameter? So you
> > > can just add something like
> > >
> > > vfio-pci.devices=:02
Hi,
This is very rough and early, but I wanted to get some feedback,
possibly advice, and see if there's some interest in at least creating
infrastructure for user contributed libvirt hooks, if not some default
ones that are no-ops unless configured.
The impetus for this is that I started trying
Hi Greg,
I think Bjorn is waiting for an ack from you on this. Do you approve of
this approach from a driver-core perspective? Thanks,
Alex
On Fri, 2014-04-04 at 14:19 -0600, Alex Williamson wrote:
> The driver_override field allows us to specify the driver for a device
> rather than r
prevent the device from binding to any driver (override
driver = "none") or perhaps have it automatically bind to vfio-pci.
With driver_override it's a simple matter for this field to be set
internally when the device is first discovered to prevent driver
matches.
Signed-off-by: A
prevent the device from binding to any driver (override
driver = "none") or perhaps have it automatically bind to vfio-pci.
With driver_override it's a simple matter for this field to be set
internally when the device is first discovered to prevent driver
matches.
Signed-off-by: A
On Mon, 10 Sep 2018 08:43:40 +0200
Gerd Hoffmann wrote:
> So we have a boot display when using a vgpu as primary display.
>
> Use vfio-pci-ramfb instead of vfio-pci to enable it.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/hw/vfio/vfio-common.h | 2 ++
> hw/vfio/display.c |
On Tue, 11 Sep 2018 06:38:43 +0200
Gerd Hoffmann 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
On Fri, 14 Sep 2018 16:19:07 +0200
Erik Skultety wrote:
> 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
> >
On Thu, 27 Sep 2018 06:48:27 +
"Tian, Kevin" wrote:
> > From: Kirti Wankhede
> > Sent: Thursday, September 27, 2018 2:22 PM
> >
> > Generally a single instance of mdev device, a share of physical device, is
> > assigned to user space application or a VM. There are cases when multiple
> > ins
On Fri, 28 Sep 2018 00:53:00 +0530
Kirti Wankhede wrote:
> On 9/27/2018 9:29 PM, Alex Williamson wrote:
> > On Thu, 27 Sep 2018 06:48:27 +
> > "Tian, Kevin" wrote:
> >
> >>> From: Kirti Wankhede
> >>> Sent: Thursday, September 27,
On Tue, 9 Oct 2018 12:11:29 +
"Wuzongyong (Euler Dept)" wrote:
> Hi,
>
> I start a virtual machine with commandline:
> /usr/libexec/qemu-kvm --enable-kvm -smp 8 -m 8192 -device
> vfio-pci,host=:81:00.0
>
> Then I pause the qemu process before executing the main_loop function by gdb
On Wed, 10 Oct 2018 01:47:10 +
"Wuzongyong (Euler Dept)" wrote:
>
> You're right. The initial states are not identical.
> I found the function vfio_pci_pre_reset in qemu.
> /*
> * Stop any ongoing DMA by disconecting I/O, MMIO, and bus master.
> * Also put INTx Disable in known
On Tue, 9 Oct 2018 01:40:17 +0530
Kirti Wankhede wrote:
> Generally a single instance of mdev device, a share of physical device, is
> assigned to user space application or a VM. There are cases when multiple
> instances of mdev devices of same or different types are required by user
> space appl
On Thu, 11 Oct 2018 09:14:22 +0800
Zhenyu Wang wrote:
> On 2018.10.10 23:22:20 +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Thursday, October 11, 2018 4:39 AM
> > >
> > > On Tue, 9 Oct 2018 01:40:17 +0530
> > > Kirti Wank
On Thu, 10 May 2018 13:00:29 +0200
Erik Skultety wrote:
> ...
>
> > > Now, if we (theoretically) can settle on easing the restrictions Alex
> > > has mentioned, we in fact could introduce a QMP command to probe
> > > these devices and provide libvirt with useful information at that
> > > point i
[Cc +Erik,libvirt]
Sorry, should have cc'd libvirt with this initially since display
support is under development. I think "off" is the better
compatibility option, but perhaps the damage is done since it was the
2.12 default. Thanks,
Alex
On Tue, 29 May 2018 09:18:10 -0600
On Wed, 13 Jun 2018 10:41:49 +0200
Gerd Hoffmann wrote:
> So we have a boot display when using a vgpu as primary display.
>
> Use vfio-pci-ramfb instead of vfio-pci to enable it.
Using a different device here seems like it almost guarantees a very
complicated path to support under libvirt. Wha
On Thu, 21 Jun 2018 19:57:38 +0530
Kirti Wankhede wrote:
> On 6/20/2018 1:10 PM, Zhenyu Wang wrote:
> > Current mdev device create interface depends on fixed mdev type, which get
> > uuid
> > from user to create instance of mdev device. If user wants to use customized
> > number of resource for
On Fri, 20 Jul 2018 10:19:24 +0800
Zhenyu Wang wrote:
> Current mdev device create interface depends on fixed mdev type, which get
> uuid
> from user to create instance of mdev device. If user wants to use customized
> number of resource for mdev device, then only can create new mdev type for
>
On Thu, 26 Jul 2018 15:50:28 +0200
Erik Skultety wrote:
> On Tue, Jul 24, 2018 at 11:44:40AM -0600, Alex Williamson wrote:
> > On Fri, 20 Jul 2018 10:19:24 +0800
> > Zhenyu Wang wrote:
> >
> > > Current mdev device create interface depends on fixed mdev type, wh
On Thu, 26 Jul 2018 17:30:07 +0200
Cornelia Huck wrote:
> On Thu, 26 Jul 2018 15:50:28 +0200
> Erik Skultety wrote:
>
> > On Tue, Jul 24, 2018 at 11:44:40AM -0600, Alex Williamson wrote:
> > > On Fri, 20 Jul 2018 10:19:24 +0800
> > > Zhenyu Wang wrote:
>
; > for mdev.
> > >
> > > Cc: Kirti Wankhede
> > > Cc: Alex Williamson
> > > Cc: Kevin Tian
> > > Signed-off-by: Zhenyu Wang
> > > ---
> > > Documentation/vfio-mediated-device.txt | 39 ++
> > > 1
On Sun, 29 Jul 2018 21:19:41 +
"Wang, Zhi A" wrote:
> BACKGROUND
>
> As the live migration of mdev is going to be supported in VFIO, a scheme of
> deciding if a mdev could be migratable between the source machine and the
> destination machine is needed. Mostly, this email is going to discu
On Wed, 1 Aug 2018 10:22:39 +
"Wang, Zhi A" wrote:
> Hi:
>
> Let me summarize the understanding so far I got from the discussions since I
> am new to this discussion.
>
> The mdev_type would be a generic stuff since we don't want userspace
> application to be confused. The example of mdev
On Fri, 3 Aug 2018 12:07:58 +
"Wang, Zhi A" wrote:
> Hi:
>
> Thanks for unfolding your idea. The picture is clearer to me now. I didn't
> realize that you also want to support cross hardware migration. Well, I
> thought for a while, the cross hardware migration might be not popular in
> v
On Tue, 31 Jul 2018 04:05:11 +0800
Zhi Wang wrote:
> On 07/30/18 23:56, Alex Williamson wrote:
> > On Sun, 29 Jul 2018 21:19:41 +
> > "Wang, Zhi A" wrote:
> >
> >> BACKGROUND
> >>
> >> As the live migration of mdev is going to
On Fri, 3 Aug 2018 08:29:39 +0200
Christian Ehrhardt wrote:
> Hi,
> I was recently looking into a case which essentially looked like this:
> 1. virsh shutdown guest
> 2. after <1 second the qemu process was gone from /proc/
> 3. but libvirt spun in virProcessKillPainfully because the proce
On Mon, 6 Aug 2018 23:45:21 +0530
Kirti Wankhede wrote:
> On 8/3/2018 11:26 PM, Alex Williamson wrote:
> > On Fri, 3 Aug 2018 12:07:58 +
> > "Wang, Zhi A" wrote:
> >
> >> Hi:
> >>
> >> Thanks for unfolding your idea. The picture
On Sun, 19 Aug 2018 22:25:19 +0800
Zhi Wang wrote:
> Share some updates of my work on this topic recently:
>
> Thanks for Erik's guide and advices. Now my PoC patches almost works.
> Will send the RFC soon.
>
> Mostly the ideas are based on Alex's idea: a match between a device
> state versio
On Wed, 22 Aug 2018 01:27:05 +
"Tian, Kevin" wrote:
> > From: Wang, Zhi A
> > Sent: Wednesday, August 22, 2018 2:43 AM
> > >
> > > Are there any suggestions how we can deal with security issues?
> > > Allowing userspace to provide a data stream representing the internal
> > > state of a vir
On Wed, 22 Aug 2018 02:30:12 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Wednesday, August 22, 2018 10:08 AM
> >
> > On Wed, 22 Aug 2018 01:27:05 +
> > "Tian, Kevin" wrote:
> &
On Thu, 23 Aug 2018 04:02:43 +
"Tian, Kevin" wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, August 23, 2018 11:47 AM
> >
> > On Wed, 22 Aug 2018 02:30:12 +
> > "Tian, Kevin" wrote:
> &g
[cc +Alexey]
On Wed, 6 Feb 2019 13:44:53 -0200
Daniel Henrique Barboza wrote:
> QEMU virtual machines with PCI passthrough of certain devices,
> such as the NVIDIA Tesla V100 GPU, requires allocation of an
> amount of memory pages that can break KVM limits. When that
> happens, the KVM module c
On Tue, 18 Jun 2019 14:48:11 +0200
Sylvain Bauza wrote:
> On Tue, Jun 18, 2019 at 1:01 PM Cornelia Huck wrote:
>
> > On Mon, 17 Jun 2019 11:05:17 -0600
> > Alex Williamson wrote:
> >
> > > On Mon, 17 Jun 2019 16:10:30 +0100
> > > Daniel P. Berra
On Wed, 19 Jun 2019 11:46:59 +0200
Cornelia Huck wrote:
> On Wed, 19 Jun 2019 08:28:02 +0100
> Daniel P. Berrangé wrote:
>
> > On Tue, Jun 18, 2019 at 04:12:10PM -0600, Alex Williamson wrote:
> > > On Tue, 18 Jun 2019 14:48:11 +0200
> > > Sylvain Bauza wrot
On Wed, 19 Jun 2019 11:04:15 +0200
Sylvain Bauza wrote:
> On Wed, Jun 19, 2019 at 12:27 AM Alex Williamson
> wrote:
>
> > On Tue, 18 Jun 2019 14:48:11 +0200
> > Sylvain Bauza wrote:
> >
> > > On Tue, Jun 18, 2019 at 1:01 PM Cornelia Huck wrote:
> >
Hi,
Based on the discussions we've had, I've rewritten the bulk of
mdevctl. I think it largely does everything we want now, modulo
devices that will need some sort of 1:N values per key for
configuration in the config file versus the 1:1 key:value setup we
currently have (so don't consider the fo
On Wed, 26 Jun 2019 11:58:06 +0200
Cornelia Huck wrote:
> On Tue, 25 Jun 2019 16:52:51 -0600
> Alex Williamson wrote:
>
> > Hi,
> >
> > Based on the discussions we've had, I've rewritten the bulk of
> > mdevctl. I think it largely does everythin
On Wed, 26 Jun 2019 08:37:20 -0600
Alex Williamson wrote:
> On Wed, 26 Jun 2019 11:58:06 +0200
> Cornelia Huck wrote:
>
> > On Tue, 25 Jun 2019 16:52:51 -0600
> > Alex Williamson wrote:
> >
> > > Hi,
> > >
> > > Based on the discussio
On Thu, 27 Jun 2019 11:00:31 -0400
Matthew Rosato wrote:
> On 6/27/19 8:26 AM, Cornelia Huck wrote:
> > On Wed, 26 Jun 2019 19:53:50 -0600
> > Alex Williamson wrote:
> >
> >> On Wed, 26 Jun 2019 08:37:20 -0600
> >> Alex Williamson wrote:
> >
On Thu, 27 Jun 2019 09:38:32 -0600
Alex Williamson wrote:
> > On 6/27/19 8:26 AM, Cornelia Huck wrote:
> > >
> > > {
> > > "foo": "1",
> > > "bar": "42",
> > > "baz": {
> > >
On Thu, 27 Jun 2019 15:15:02 -0600
Alex Williamson wrote:
> On Thu, 27 Jun 2019 09:38:32 -0600
> Alex Williamson wrote:
> > > On 6/27/19 8:26 AM, Cornelia Huck wrote:
> > > >
> > > > {
> > > > "foo": "1",
> &
On Fri, 28 Jun 2019 11:06:48 +0200
Cornelia Huck wrote:
> On Thu, 27 Jun 2019 19:57:04 -0600
> Alex Williamson wrote:
>
> > On Thu, 27 Jun 2019 15:15:02 -0600
> > Alex Williamson wrote:
> >
> > > On Thu, 27 Jun 2019 09:38:32 -0600
> > > Alex Wil
On Mon, 1 Jul 2019 10:20:43 +0200
Cornelia Huck wrote:
> On Fri, 28 Jun 2019 11:05:46 -0600
> Alex Williamson wrote:
>
> > On Fri, 28 Jun 2019 11:06:48 +0200
> > Cornelia Huck wrote:
>
> > > What do you think of a way to specify JSON for the attributes d
On Thu, 18 Jul 2019 17:08:23 -0400
Laine Stump wrote:
> On 7/18/19 2:58 PM, Daniel Henrique Barboza wrote:
> >
> > On 7/18/19 2:18 PM, Laine Stump wrote:
> >
> >> But to back up a bit - what is it about managed='yes' that makes you
> >> want to do it that way instead of managed='no'? Do you re
On Mon, 7 Oct 2019 18:11:32 -0300
Daniel Henrique Barboza wrote:
> (--- long post warning ---)
>
> This is a work that derived from the discussions I had with
> Laine Stump and Alex Williamson in [1]. I'll provide a quick
> gist below.
>
> --
>
> Tod
On Mon, 9 Apr 2018 12:35:10 +0200
Gerd Hoffmann wrote:
> This little series adds three drivers, for demo-ing and testing vfio
> display interface code. There is one mdev device for each interface
> type (mdpy.ko for region and mbochs.ko for dmabuf).
Erik Skultety brought up a good question tod
On Thu, 19 Apr 2018 10:40:18 +0200
Gerd Hoffmann wrote:
> > So I was ready to return and suggest that maybe libvirt should probe
> > the device to know about these ancillary configuration details, but
> > then I remembered that both mdev vGPU vendors had external dependencies
> > to even allow pro
On Wed, 18 Apr 2018 12:31:53 -0600
Alex Williamson wrote:
> On Mon, 9 Apr 2018 12:35:10 +0200
> Gerd Hoffmann wrote:
>
> > This little series adds three drivers, for demo-ing and testing vfio
> > display interface code. There is one mdev device for each interface
> &g
On Tue, 24 Apr 2018 09:17:37 +0200
Gerd Hoffmann 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'
On Wed, 25 Apr 2018 01:20:08 +0530
Kirti Wankhede wrote:
> On 4/24/2018 3:10 AM, Alex Williamson wrote:
> > On Wed, 18 Apr 2018 12:31:53 -0600
> > Alex Williamson wrote:
> >
> >> On Mon, 9 Apr 2018 12:35:10 +0200
> >> Gerd Hoffmann wrote:
> >&g
On Wed, 25 Apr 2018 21:00:39 +0530
Kirti Wankhede wrote:
> On 4/25/2018 4:29 AM, Alex Williamson wrote:
> > On Wed, 25 Apr 2018 01:20:08 +0530
> > Kirti Wankhede wrote:
> >
> >> On 4/24/2018 3:10 AM, Alex Williamson wrote:
> >>> On Wed, 18 Apr
On Thu, 26 Apr 2018 08:14:27 +0200
Gerd Hoffmann wrote:
> On Thu, Apr 26, 2018 at 03:44:15AM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Thursday, April 19, 2018 2:32 AM
> > >
> > > That almost begins to look reasonable, but then
On Thu, 26 Apr 2018 19:55:23 +0100
"Dr. David Alan Gilbert" wrote:
> * Kirti Wankhede (kwankh...@nvidia.com) wrote:
> >
> >
> > On 4/26/2018 1:22 AM, Dr. David Alan Gilbert wrote:
> > > * Alex Williamson (alex.william...@redhat.com) wrote:
&
Hi,
The previous discussion hasn't produced results, so let's start over.
Here's the situation:
- We currently have kernel and QEMU support for the QEMU vfio-pci
display option.
- The default for this option is 'auto', so the device will attempt to
generate a display if the underlying de
On Fri, 4 May 2018 09:49:44 +0200
Erik Skultety wrote:
> On Thu, May 03, 2018 at 12:58:00PM -0600, Alex Williamson wrote:
> > Hi,
> >
> > The previous discussion hasn't produced results, so let's start over.
> > Here's the situation:
> >
> >
On Fri, 4 May 2018 10:16:09 +0100
Daniel P. Berrangé wrote:
> On Thu, May 03, 2018 at 12:58:00PM -0600, Alex Williamson wrote:
> > Hi,
> >
> > The previous discussion hasn't produced results, so let's start over.
> > Here's the situation:
> >
On Wed, 2013-02-06 at 14:13 -0500, Laine Stump wrote:
> Now that qemu is getting the q35 machine type, libvirt needs to
> support it.
>
> As far as I understand, from libvirt's point of view, q35 is just
> another x86_64 system, but with a different set of implicit devices,
> and possibly some ext
On Thu, 2013-02-07 at 17:31 +, Daniel P. Berrange wrote:
> On Wed, Feb 06, 2013 at 01:15:05PM -0700, Alex Williamson wrote:
> > On Wed, 2013-02-06 at 14:13 -0500, Laine Stump wrote:
> > > 2) Are there other issues aside from implicit controller devices I
> > > ne
On Wed, 2013-02-27 at 13:20 -0500, Laine Stump wrote:
> On 02/06/2013 02:13 PM, Laine Stump wrote:
> > Now that qemu is getting the q35 machine type, libvirt needs to support it.
>
> In an attempt to make sure that libvirt actually does something useful
> with qemu's new machine type, I'm revisiti
On Mon, 2013-03-11 at 13:23 -0400, Laine Stump wrote:
> VFIO is a new method of doing PCI device assignment ("PCI passthrough"
> aka "") available in newish kernels (3.6?; it's in Fedora 18 at
> any rate) and via the "vfio-pci" device in qemu-1.4+. In contrast to the
> traditional KVM PCI device as
On Tue, 2013-03-12 at 13:20 -0400, Laine Stump wrote:
> On 03/11/2013 02:06 PM, Alex Williamson wrote:
> > On Mon, 2013-03-11 at 13:23 -0400, Laine Stump wrote:
> >> VFIO is a new method of doing PCI device assignment ("PCI passthrough"
> >> aka "&qu
On Fri, 2013-04-05 at 14:42 -0400, Laine Stump wrote:
> On 04/05/2013 01:38 PM, Daniel P. Berrange wrote:
> > On Fri, Apr 05, 2013 at 12:32:04PM -0400, Laine Stump wrote:
> >> On 04/03/2013 11:50 AM, Ján Tomko wrote:
> >>> From: liguang
> >>>
> >>> add a new controller type, then one can
> >>> def
On Mon, 2013-04-08 at 12:37 -0400, Laine Stump wrote:
> On 04/05/2013 03:26 PM, Alex Williamson wrote:
> > On Fri, 2013-04-05 at 14:42 -0400, Laine Stump wrote:
> >> On 04/05/2013 01:38 PM, Daniel P. Berrange wrote:
> >>> On Fri, Apr 05, 2013 at 12:32:04PM -0400, Lain
On Fri, 2013-04-12 at 11:46 -0400, Laine Stump wrote:
> On 04/11/2013 07:23 AM, Michael S. Tsirkin wrote:
> > On Thu, Apr 11, 2013 at 07:03:56AM -0400, Laine Stump wrote:
> >> On 04/10/2013 05:26 AM, Daniel P. Berrange wrote:
> >>> On Tue, Apr 09, 2013 at 04:06:06PM -0400, Laine Stump wrote:
>
Hey folks,
We'd like to hold another virtualization microconference as part of this
year's Linux Plumbers Conference. To do so, we need to show that
there's enough interest, materials, and people willing to attend.
Anthony and Amit have already started a wiki page for the
microconference:
http
On Thu, 2013-05-30 at 12:29 -0400, Laine Stump wrote:
> VFIO device assignment has a concept of device "groups"; each group is a
> set of devices that must all be assigned to the same guest (alternately,
> unassigned devices can be attached to the vfio stub driver). This is to
> prevent cross-guest
On Thu, 2013-05-30 at 13:48 -0400, Laine Stump wrote:
> On 05/30/2013 01:18 PM, Alex Williamson wrote:
> > nit, vfio is not a stub driver, it's an actual driver. vfio also
> > whitelists some host drivers. The two so far are pci-stub and
> > pcieport. libvirt should not
s, both ways are fine. But you should at least have a comment.
>
> >> Apart from that, the code you posted below makes sense.
> >
> > Even with the 1GB addition for VFIO? I have to admit I'm a bit ignorant
> > of VFIO but shouldn't that limit be derived from th
The Call for Proposals for the 2013 Linux Plumbers Virtualization
Microconference is now open. This uconf is being held as part of Linux
Plumbers Conference in New Orleans, Louisiana, USA September 18-20th and
is co-located with LinuxCon North America. For more information see:
http://www.linux
On Fri, 2013-07-12 at 14:38 -0600, Alex Williamson wrote:
> The Call for Proposals for the 2013 Linux Plumbers Virtualization
> Microconference is now open. This uconf is being held as part of Linux
> Plumbers Conference in New Orleans, Louisiana, USA September 18-20th and
> is co-
1 - 100 of 287 matches
Mail list logo
