On Tue, 17 Oct 2023 12:28:30 -0300
Jason Gunthorpe wrote:
> On Tue, Oct 17, 2023 at 09:21:16AM -0600, Alex Williamson wrote:
>
> > Do we therefore need some programatic means for the kernel driver to
> > expose the node configuration to userspace? What interfaces would
>
On Tue, 17 Oct 2023 14:00:54 +
Ankit Agrawal wrote:
> >> -device
> >>vfio-pci-nohotplug,host=0009:01:00.0,bus=pcie.0,addr=04.0,rombar=0,id=dev0 \
> >> -object
> >>nvidia-acpi-generic-initiator,id=gi0,device=dev0,numa-node-start=2,numa-node-count=8
> >>
> >
> > Why didn't
_KERNEL_ACCOUNT.
> - s/VFIO_PCI_ACPI_NTFY_IRQ_INDEX/VFIO_PCI_ACPI_IRQ_INDEX.
> - Add header protection for multiple includes.
> - v4:
> https://patchwork.kernel.org/project/kvm/patch/20230522165811.123417-1-...@semihalf.com/
>
> Changelog v3..v4
> Address Alex Williamson fee
On Wed, 7 Jun 2023 22:22:12 +0200
Grzegorz Jaszczyk wrote:
> > >
> > > Can we drop the NTFY and just use VFIO_PCI_ACPI_IRQ_INDEX?
> >
> > ACPI_IRQ at first glance could be confused with SCI, which is e.g.
> > registered as "acpi" irq seen in /proc/interrupts, maybe it is worth
> > keeping NTFY
On Wed, 31 May 2023 17:46:50 -0300
Jason Gunthorpe wrote:
> On Wed, May 31, 2023 at 02:40:01PM -0600, Alex Williamson wrote:
>
> > Also note that we're saying "vfio" not "vfio-pci". Only the mdev
> > interface has the device_api attribute to indicate
er, e.g.:
>
> /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
>
> It is also a preparatory step toward adding cdev for supporting future
> device-oriented uAPI.
>
> Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
>
>
d up with notification values being coalesced. Therefore ACPI
> notification values are buffered and signalized one by one, when the
> previous notification value has been consumed.
>
> Signed-off-by: Grzegorz Jaszczyk
> ---
> Changelog v3..v4
> Address Alex Williamson feedback:
On Tue, 2 May 2023 13:27:00 +
Grzegorz Jaszczyk wrote:
> From: Grzegorz Jaszczyk
>
> To allow pass-through devices receiving ACPI notifications, permit to
> register ACPI notify handler (via introduced new ioctl) for a given
This shouldn't require a new ioctl, it should fit within the
On Thu, 9 Mar 2023 14:41:23 +0100
Grzegorz Jaszczyk wrote:
> czw., 9 mar 2023 o 00:38 Alex Williamson
> napisał(a):
> >
> > On Wed, 8 Mar 2023 14:44:28 -0800
> > Dominik Behr wrote:
> >
> > > On Wed, Mar 8, 2023 at 12:06 PM Alex Williamson
> > &
On Wed, 8 Mar 2023 14:44:28 -0800
Dominik Behr wrote:
> On Wed, Mar 8, 2023 at 12:06 PM Alex Williamson
> wrote:
> >
> > On Wed, 8 Mar 2023 10:45:51 -0800
> > Dominik Behr wrote:
> >
> > > It is the same interface as other ACPI events like AC adapter LI
On Wed, 8 Mar 2023 10:45:51 -0800
Dominik Behr wrote:
> On Wed, Mar 8, 2023 at 9:49 AM Alex Williamson
> wrote:
>
> > Adding libvirt folks. This intentionally designs the interface in a
> > way that requires a privileged intermediary to monitor netlink on the
> &g
[Cc +libvir-list]
On Wed, 8 Mar 2023 12:41:24 +0100
Grzegorz Jaszczyk wrote:
> śr., 8 mar 2023 o 00:42 Alex Williamson
> napisał(a):
> >
> > On Tue, 7 Mar 2023 22:05:53 +
> > Grzegorz Jaszczyk wrote:
> >
> > > From: Dominik Behr
&g
On Fri, 23 Sep 2022 10:29:41 -0300
Jason Gunthorpe wrote:
> On Fri, Sep 23, 2022 at 09:54:48AM +0100, Daniel P. Berrangé wrote:
>
> > Yes, we use cgroups extensively already.
>
> Ok, I will try to see about this
>
> Can you also tell me if the selinux/seccomp will prevent qemu from
>
[Cc+ Steve, libvirt, Daniel, Laine]
On Tue, 20 Sep 2022 16:56:42 -0300
Jason Gunthorpe wrote:
> On Tue, Sep 13, 2022 at 09:28:18AM +0200, Eric Auger wrote:
> > Hi,
> >
> > On 9/13/22 03:55, Tian, Kevin wrote:
> > > We didn't close the open of how to get this merged in LPC due to the
> > >
On Tue, 23 Aug 2022 10:11:32 -0400
Laine Stump wrote:
> ping.
>
> I have a different version of this patch where I do read the
> modules.alias file rather than just checking the name of the driver, but
> that also requires "double mocking" open() in the unit test, which
> wasn't working
On Fri, 5 Aug 2022 15:20:24 -0300
Jason Gunthorpe wrote:
> On Fri, Aug 05, 2022 at 11:24:08AM -0600, Alex Williamson wrote:
> > On Thu, 4 Aug 2022 21:11:07 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Thu, Aug 04, 2022 at 01:36:24P
On Thu, 4 Aug 2022 21:11:07 -0300
Jason Gunthorpe wrote:
> On Thu, Aug 04, 2022 at 01:36:24PM -0600, Alex Williamson wrote:
>
> > > > That is reasonable, but I'd say those three kernels only have two
> > > > drivers and they both have vfio as a substring in thei
On Thu, 4 Aug 2022 15:11:07 -0400
Laine Stump wrote:
> On 8/4/22 2:36 PM, Jason Gunthorpe wrote:
> > On Thu, Aug 04, 2022 at 12:18:26PM -0600, Alex Williamson wrote:
> >> On Thu, 4 Aug 2022 13:51:20 -0300
> >> Jason Gunthorpe wrote:
> >>
> >>>
On Thu, 4 Aug 2022 13:51:20 -0300
Jason Gunthorpe wrote:
> On Mon, Aug 01, 2022 at 09:49:28AM -0600, Alex Williamson wrote:
>
> > > > > > Fortunately these new vendor/device-specific drivers can be easily
> > > > > > identified as being &q
On Mon, 1 Aug 2022 16:02:05 +0200
Erik Skultety wrote:
> Putting Alex on CC since I don't see him there:
> +alex.william...@redhat.com
Hmm, Laine cc'd me on the initial post but it seems it got dropped
somewhere.
> On Mon, Aug 01, 2022 at 09:30:38AM -0400, Laine Stump wrote:
> > On 8/1/22
On Thu, 28 Apr 2022 03:21:45 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, April 27, 2022 12:22 AM
> > > >
> > > > My expectation would be that libvirt uses:
> > > >
> > > > -object iommuf
On Tue, 26 Apr 2022 13:42:17 -0300
Jason Gunthorpe wrote:
> On Tue, Apr 26, 2022 at 10:21:59AM -0600, Alex Williamson wrote:
> > We also need to be able to advise libvirt as to how each iommufd object
> > or user of that object factors into the VM locked memory requirement.
> &
On Tue, 26 Apr 2022 08:37:41 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Monday, April 25, 2022 10:38 PM
> >
> > On Mon, 25 Apr 2022 11:10:14 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Fri, Apr 22, 2022 at
On Mon, 25 Apr 2022 22:23:05 +0200
Eric Auger wrote:
> Hi Alex,
>
> On 4/23/22 12:09 AM, Alex Williamson wrote:
> > [Cc +libvirt folks]
> >
> > On Thu, 14 Apr 2022 03:46:52 -0700
> > Yi Liu wrote:
> >
> >> With the introduction of
On Mon, 25 Apr 2022 11:10:14 +0100
Daniel P. Berrangé wrote:
> On Fri, Apr 22, 2022 at 04:09:43PM -0600, Alex Williamson wrote:
> > [Cc +libvirt folks]
> >
> > On Thu, 14 Apr 2022 03:46:52 -0700
> > Yi Liu wrote:
> >
> > > With the introductio
[Cc +libvirt folks]
On Thu, 14 Apr 2022 03:46:52 -0700
Yi Liu wrote:
> With the introduction of iommufd[1], the linux kernel provides a generic
> interface for userspace drivers to propagate their DMA mappings to kernel
> for assigned devices. This series does the porting of the VFIO devices
>
On Fri, 18 Jun 2021 10:43:07 -0400
Laine Stump wrote:
> On 6/16/21 4:15 PM, Daniel Henrique Barboza wrote:
> >
> >
> > On 6/9/21 4:38 PM, Manish Mishra wrote:
> >> Hi Everyone,
> >>
> >> We want to add extra options to device xml to skip reattach of pci
> >> passthrough devices. Following
On Mon, 1 Feb 2021 16:57:44 -0600
Jonathon Jongsma wrote:
> On Mon, 1 Feb 2021 11:33:08 +0100
> Erik Skultety wrote:
>
> > On Mon, Feb 01, 2021 at 09:48:11AM +, Daniel P. Berrangé wrote:
> > > On Mon, Feb 01, 2021 at 10:45:43AM +0100, Erik Skultety wrote:
> > > > On Mon, Feb 01, 2021
On Wed, 07 Oct 2020 19:59:36 +0100
steve wrote:
> Original message
> From: Alex Williamson
> Date: 07/10/2020 18:08 (GMT+00:00)
> To: Steven Newbury
> Cc: Peter Krempa , libvir-list@redhat.com
> Subject: Re: [PATCH] Support x-vga=on for PCI host p
On Wed, 07 Oct 2020 14:20:21 +0100
Steven Newbury wrote:
> On Wed, 2020-10-07 at 15:07 +0200, Peter Krempa wrote:
> > On Wed, Oct 07, 2020 at 13:59:35 +0100, Steven Newbury wrote:
> > > When using a passthrough GPU with libvirt there is no option to
> > > pass "x-vga=on" to the device
On Mon, 14 Sep 2020 13:48:43 +
"Zeng, Xin" wrote:
> On Saturday, September 12, 2020 12:52 AM
> Alex Williamson wrote:
> > To: Zhao, Yan Y
> > Cc: Sean Mooney ; Cornelia Huck
> > ; Daniel P.Berrangé ;
> > k...@vger.kernel.org; libvir-list@redhat.com
On Fri, 11 Sep 2020 08:56:00 +0800
Yan Zhao wrote:
> On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote:
> > On Thu, 10 Sep 2020 13:50:11 +0100
> > Sean Mooney wrote:
> >
> > > On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> > &
On Thu, 10 Sep 2020 13:50:11 +0100
Sean Mooney wrote:
> On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> > On Wed, 9 Sep 2020 10:13:09 +0800
> > Yan Zhao wrote:
> >
> > > > > still, I'd like to put it more explicitly to make ensure it's not
> > > > > missed:
> > > > > the reason we
On Thu, 20 Aug 2020 08:39:22 +0800
Yan Zhao wrote:
> On Tue, Aug 18, 2020 at 11:36:52AM +0200, Cornelia Huck wrote:
> > On Tue, 18 Aug 2020 10:16:28 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Tue, Aug 18, 2020 at 05:01:51PM +0800, Jason Wang wrote:
> > > >On 2020/8/18 下午4:55,
On Thu, 20 Aug 2020 08:18:10 +0800
Yan Zhao wrote:
> On Wed, Aug 19, 2020 at 11:50:21AM -0600, Alex Williamson wrote:
> <...>
> > > > > > What I care about is that we have a *standard* userspace API for
> > > > > > performing device c
l.com; kevin.t...@intel.com;
> > > Parav Pandit ; jian-feng.d...@intel.com;
> > > dgilb...@redhat.com; zhen...@linux.intel.com; hejie...@intel.com;
> > > bao.yum...@zte.com.cn; Alex Williamson ;
> > > eskul...@redhat.com; smoo...@redhat.com; intel-gvt-
> > > d
On Thu, 30 Jul 2020 11:41:04 +0800
Yan Zhao wrote:
> On Wed, Jul 29, 2020 at 01:12:55PM -0600, Alex Williamson wrote:
> > On Wed, 29 Jul 2020 12:28:46 +0100
> > Sean Mooney wrote:
> >
> > > On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > > >
On Wed, 29 Jul 2020 12:28:46 +0100
Sean Mooney wrote:
> On Wed, 2020-07-29 at 16:05 +0800, Yan Zhao wrote:
> > On Mon, Jul 27, 2020 at 04:23:21PM -0600, Alex Williamson wrote:
> > > On Mon, 27 Jul 2020 15:24:40 +0800
> > > Yan Zhao wrote:
> > >
>
On Mon, 27 Jul 2020 15:24:40 +0800
Yan Zhao wrote:
> > > As you indicate, the vendor driver is responsible for checking version
> > > information embedded within the migration stream. Therefore a
> > > migration should fail early if the devices are incompatible. Is it
> > but as I know,
On Fri, 17 Jul 2020 19:03:44 +0100
"Dr. David Alan Gilbert" wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > On Wed, 15 Jul 2020 16:20:41 +0800
> > Yan Zhao wrote:
> >
> > > On Tue, Jul 14, 2020 at 02:59:48PM -0600, Alex Williamson wr
On Thu, 16 Jul 2020 16:32:30 +0800
Yan Zhao wrote:
> On Thu, Jul 16, 2020 at 12:16:26PM +0800, Jason Wang wrote:
> >
> > On 2020/7/14 上午7:29, Yan Zhao wrote:
> > > hi folks,
> > > we are defining a device migration compatibility interface that helps
> > > upper
> > > layer stack like
On Wed, 15 Jul 2020 15:37:19 +0800
Alex Xu wrote:
> Alex Williamson 于2020年7月15日周三 上午5:00写道：
>
> > On Tue, 14 Jul 2020 18:19:46 +0100
> > "Dr. David Alan Gilbert" wrote:
> >
> > > * Alex Williamson (alex.william...@redhat.com) wrote:
On Wed, 15 Jul 2020 16:20:41 +0800
Yan Zhao wrote:
> On Tue, Jul 14, 2020 at 02:59:48PM -0600, Alex Williamson wrote:
> > On Tue, 14 Jul 2020 18:19:46 +0100
> > "Dr. David Alan Gilbert" wrote:
> >
> > > * Alex Williamson (alex.william...@redhat.com) wr
On Tue, 14 Jul 2020 18:19:46 +0100
"Dr. David Alan Gilbert" wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > On Tue, 14 Jul 2020 11:21:29 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Tue, Jul 14, 2020 at 07:29:57AM +0800, Yan Zh
On Tue, 14 Jul 2020 17:47:22 +0100
Daniel P. Berrangé wrote:
> On Tue, Jul 14, 2020 at 10:16:16AM -0600, Alex Williamson wrote:
> > On Tue, 14 Jul 2020 11:21:29 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Tue, Jul 14, 2020 at 07
On Tue, 14 Jul 2020 13:33:24 +0100
Sean Mooney wrote:
> On Tue, 2020-07-14 at 11:21 +0100, Daniel P. Berrangé wrote:
> > On Tue, Jul 14, 2020 at 07:29:57AM +0800, Yan Zhao wrote:
> > > hi folks,
> > > we are defining a device migration compatibility interface that helps
> > > upper
> > >
On Tue, 14 Jul 2020 11:21:29 +0100
Daniel P. Berrangé wrote:
> On Tue, Jul 14, 2020 at 07:29:57AM +0800, Yan Zhao wrote:
> > hi folks,
> > we are defining a device migration compatibility interface that helps upper
> > layer stack like openstack/ovirt/libvirt to check if two devices are
> > live
On Tue, 9 Jun 2020 20:37:31 -0400
Yan Zhao wrote:
> On Fri, Jun 05, 2020 at 03:39:50PM +0100, Dr. David Alan Gilbert wrote:
> > > > > I tried to simplify the problem a bit, but we keep going backwards.
> > > > > If
> > > > > the requirement is that potentially any source device can migrate to
On Fri, 5 Jun 2020 11:22:24 +0100
"Dr. David Alan Gilbert" wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > On Wed, 3 Jun 2020 01:24:43 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrot
On Wed, 3 Jun 2020 01:24:43 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 09:55:28PM -0600, Alex Williamson wrote:
> > On Tue, 2 Jun 2020 23:19:48 -0400
> > Yan Zhao wrote:
> >
> > > On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> &
On Tue, 2 Jun 2020 23:19:48 -0400
Yan Zhao wrote:
> On Tue, Jun 02, 2020 at 04:55:27PM -0600, Alex Williamson wrote:
> > On Wed, 29 Apr 2020 20:39:50 -0400
> > Yan Zhao wrote:
> >
> > > On Wed, Apr 29, 2020 at 05:48:44PM +0800
On Wed, 29 Apr 2020 20:39:50 -0400
Yan Zhao wrote:
> On Wed, Apr 29, 2020 at 05:48:44PM +0800, Dr. David Alan Gilbert wrote:
>
> > > > > > > > > > > > > > An mdev type is meant to define a software
> > > > > > > > > > > > > > compatible interface, so in
> > > > > > > > > > > > > > the case of
On Sun, 19 Apr 2020 21:24:57 -0400
Yan Zhao wrote:
> On Fri, Apr 17, 2020 at 07:24:57PM +0800, Cornelia Huck wrote:
> > On Fri, 17 Apr 2020 05:52:02 -0400
> > Yan Zhao wrote:
> >
> > > On Fri, Apr 17, 2020 at 04:44:50PM +0800, Cornelia Huck wrote:
> > > > On Mon, 13 Apr 2020 01:52:01 -0400
On Tue, 24 Mar 2020 09:23:31 +
"Dr. David Alan Gilbert" wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
> > On Tue, Mar 24, 2020 at 05:29:59AM +0800, Alex Williamson wrote:
> > > On Mon, 3 Jun 2019 20:34:22 -0400
> > > Yan Zhao wrote:
> > >
On Mon, 3 Jun 2019 20:34:22 -0400
Yan Zhao wrote:
> On Tue, Jun 04, 2019 at 03:29:32AM +0800, Alex Williamson wrote:
> > On Thu, 30 May 2019 20:44:38 -0400
> > Yan Zhao wrote:
> >
> > > This patchset introduces a migration_version attribute under sysfs
On Tue, 17 Dec 2019 17:35:01 -0300
Daniel Henrique Barboza wrote:
> changes from previous version 5 [1]:
> - changes in the commit message of patch 1 and the
> documentation included in patches 3 and 4, all of them
> suggested/hinted by Alex Williamson.
Seems conceptually sound
On Tue, 17 Dec 2019 16:06:47 -0300
Daniel Henrique Barboza wrote:
> Signed-off-by: Daniel Henrique Barboza
> ---
> docs/news.xml | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/docs/news.xml b/docs/news.xml
> index 2a25b6ca49..febda970f6 100644
> --- a/docs/news.xml
>
On Tue, 17 Dec 2019 16:06:46 -0300
Daniel Henrique Barboza wrote:
> Signed-off-by: Daniel Henrique Barboza
> ---
> docs/formatdomain.html.in | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
> index
On Tue, 17 Dec 2019 16:06:44 -0300
Daniel Henrique Barboza wrote:
> Today, to use a PCI hostdev "A" in a domain, all PCI devices
> that belongs to the same IOMMU group must also be declared in
> the domain XML, meaning that all IOMMU devices are detached
> from the host and all of them are
On Tue, 17 Dec 2019 13:43:14 -0300
Daniel Henrique Barboza wrote:
> On 12/17/19 1:32 PM, Alex Williamson wrote:
> > On Tue, 17 Dec 2019 11:25:38 -0500
> > Laine Stump wrote:
> >
> >> On 12/16/19 6:03 PM, Daniel Henrique Barboza wrote:
> >>&
On Tue, 17 Dec 2019 11:25:38 -0500
Laine Stump wrote:
> On 12/16/19 6:03 PM, Daniel Henrique Barboza wrote:
> >
> >
> > On 12/16/19 7:28 PM, Cole Robinson wrote:
> >> On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> >>> changes from version 3 [1]:
> >>> - removed last 2 patches that
On Mon, 16 Dec 2019 21:09:20 -0300
Daniel Henrique Barboza wrote:
> On 12/16/19 8:43 PM, Alex Williamson wrote:
> > On Mon, 16 Dec 2019 20:24:56 -0300
> > Daniel Henrique Barboza wrote:
> >
> >>
> >> The code isn't forcing a device to be assign
On Mon, 16 Dec 2019 20:24:56 -0300
Daniel Henrique Barboza wrote:
> On 12/16/19 8:06 PM, Alex Williamson wrote:
> > On Mon, 16 Dec 2019 17:28:28 -0500
> > Cole Robinson wrote:
> >
> >> On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> >>> cha
On Mon, 16 Dec 2019 17:28:28 -0500
Cole Robinson wrote:
> On 12/16/19 8:36 AM, Daniel Henrique Barboza wrote:
> > changes from version 3 [1]:
> > - removed last 2 patches that made function 0 of
> > PCI multifunction devices mandatory
> > - new patch: news.xml update
> > - changed 'since'
On Thu, 12 Dec 2019 12:09:48 +0800
Jason Wang wrote:
> On 2019/12/7 上午1:42, Alex Williamson wrote:
> > On Fri, 6 Dec 2019 17:40:02 +0800
> > Jason Wang wrote:
> >
> >> On 2019/12/6 下午4:22, Yan Zhao wrote:
> >>> On Thu, Dec 05, 2019 at 09:05:54PM +0
On Wed, 11 Dec 2019 21:02:40 -0500
Yan Zhao wrote:
> On Thu, Dec 12, 2019 at 02:56:55AM +0800, Alex Williamson wrote:
> > On Wed, 11 Dec 2019 01:25:55 -0500
> > Yan Zhao wrote:
> >
> > > On Wed, Dec 11, 2019 at 12:38:05AM +0800, Alex Williamson wrote:
> &
On Wed, 11 Dec 2019 01:25:55 -0500
Yan Zhao wrote:
> On Wed, Dec 11, 2019 at 12:38:05AM +0800, Alex Williamson wrote:
> > On Tue, 10 Dec 2019 02:44:44 -0500
> > Yan Zhao wrote:
> >
> > > On Tue, Dec 10, 2019 at 05:16:08AM +0800, Alex Williamson wrote:
>
On Mon, 9 Dec 2019 21:44:23 -0500
Yan Zhao wrote:
> > > > > Currently, yes, i40e has build dependency on vfio-pci.
> > > > > It's like this, if i40e decides to support SRIOV and compiles in vf
> > > > > related code who depends on vfio-pci, it will also have build
> > > > > dependency
> > > > >
On Tue, 10 Dec 2019 02:44:44 -0500
Yan Zhao wrote:
> On Tue, Dec 10, 2019 at 05:16:08AM +0800, Alex Williamson wrote:
> > On Mon, 9 Dec 2019 01:22:12 -0500
> > Yan Zhao wrote:
> >
> > > On Fri, Dec 06, 2019 at 11:20:38PM +0800, Alex Williamson wrote:
>
On Sun, 8 Dec 2019 22:42:25 -0500
Yan Zhao wrote:
> On Sat, Dec 07, 2019 at 05:22:26AM +0800, Alex Williamson wrote:
> > On Fri, 6 Dec 2019 02:56:55 -0500
> > Yan Zhao wrote:
> >
> > > On Fri, Dec 06, 2019 at 07:55:19AM +0800, Alex Williamson wrote:
> &
On Mon, 9 Dec 2019 01:22:12 -0500
Yan Zhao wrote:
> On Fri, Dec 06, 2019 at 11:20:38PM +0800, Alex Williamson wrote:
> > On Fri, 6 Dec 2019 01:04:07 -0500
> > Yan Zhao wrote:
> >
> > > On Fri, Dec 06, 2019 at 07:55:30AM +0800, Alex Williamson wrote:
> &
On Fri, 6 Dec 2019 02:56:55 -0500
Yan Zhao wrote:
> On Fri, Dec 06, 2019 at 07:55:19AM +0800, Alex Williamson wrote:
> > On Wed, 4 Dec 2019 22:25:36 -0500
> > Yan Zhao wrote:
> >
> > > when vfio-pci is bound to a physical device, almost all the hardware
>
On Fri, 6 Dec 2019 17:40:02 +0800
Jason Wang wrote:
> On 2019/12/6 下午4:22, Yan Zhao wrote:
> > On Thu, Dec 05, 2019 at 09:05:54PM +0800, Jason Wang wrote:
> >> On 2019/12/5 下午4:51, Yan Zhao wrote:
> >>> On Thu, Dec 05, 2019 at 02:33:19PM +0800, Jason Wang wrote:
> Hi:
>
> On
On Fri, 6 Dec 2019 01:04:07 -0500
Yan Zhao wrote:
> On Fri, Dec 06, 2019 at 07:55:30AM +0800, Alex Williamson wrote:
> > On Wed, 4 Dec 2019 22:26:50 -0500
> > Yan Zhao wrote:
> >
> > > Dynamic trap bar info region is a channel for QEMU and vendor driver to
On Wed, 4 Dec 2019 22:25:36 -0500
Yan Zhao wrote:
> when vfio-pci is bound to a physical device, almost all the hardware
> resources are passthroughed.
> Sometimes, vendor driver of this physcial device may want to mediate some
> hardware resource access for a short period of time, e.g. dirty
On Wed, 4 Dec 2019 22:26:38 -0500
Yan Zhao wrote:
> Vendor driver specifies when to support a migration region through cap
> VFIO_PCI_DEVICE_CAP_MIGRATION in vfio_pci_mediate_ops->open().
>
> If vfio-pci detects this cap, it creates a default migration region on
> behalf of vendor driver with
On Wed, 4 Dec 2019 22:26:50 -0500
Yan Zhao wrote:
> Dynamic trap bar info region is a channel for QEMU and vendor driver to
> communicate dynamic trap info. It is of type
> VFIO_REGION_TYPE_DYNAMIC_TRAP_BAR_INFO and subtype
> VFIO_REGION_SUBTYPE_DYNAMIC_TRAP_BAR_INFO.
>
> This region has two
On Thu, 21 Nov 2019 19:19:13 -0300
Daniel Henrique Barboza wrote:
> Changes from previous version [1], all of them result of
> feedback from Alex Williamson and Abdulla Bubshait:
> - use instead of creating a new subsys
> attribute;
> - expand the change to all PCI hostdevs.
On Fri, 15 Nov 2019 04:24:35 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Thursday, November 7, 2019 2:45 AM
> >
> > On Wed, 6 Nov 2019 12:20:31 +0800
> > Zhenyu Wang wrote:
> >
> > > On 2019.11.05 14:10:42 -0700, Ale
Hey folks,
We had some discussions at KVM Forum around mdev live migration and
what that might mean for libvirt handling of mdev devices and
potential libvirt/mdevctl[1] flows. I believe the current situation is
that libvirt knows nothing about an mdev beyond the UUID in the XML.
It expects the
On Wed, 6 Nov 2019 12:20:31 +0800
Zhenyu Wang wrote:
> On 2019.11.05 14:10:42 -0700, Alex Williamson wrote:
> > On Thu, 24 Oct 2019 13:08:23 +0800
> > Zhenyu Wang wrote:
> >
> > > Hi,
> > >
> > > This is a refresh for previous send of th
On Thu, 24 Oct 2019 13:08:23 +0800
Zhenyu Wang wrote:
> Hi,
>
> This is a refresh for previous send of this series. I got impression that
> some SIOV drivers would still deploy their own create and config method so
> stopped effort on this. But seems this would still be useful for some other
>
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.
>
> --
>
> Today, L
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
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 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 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 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 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 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 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
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
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:
> >
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 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 Mon, 17 Jun 2019 16:10:30 +0100
Daniel P. Berrangé wrote:
> On Mon, Jun 17, 2019 at 08:54:38AM -0600, Alex Williamson wrote:
> > On Mon, 17 Jun 2019 15:00:00 +0100
> > Daniel P. Berrangé wrote:
> >
> > > On Thu, May 23, 2019 at 05:20:01PM -0600, Alex
On Mon, 17 Jun 2019 15:00:00 +0100
Daniel P. Berrangé wrote:
> On Thu, May 23, 2019 at 05:20:01PM -0600, Alex Williamson wrote:
> > Hi,
> >
> > Currently mediated device management, much like SR-IOV VF management,
> > is largely left as an exercise for th
On Fri, 14 Jun 2019 17:06:15 +0200
Christophe de Dinechin wrote:
> > On 14 Jun 2019, at 16:23, Alex Williamson
> > wrote:
> >
> > On Fri, 14 Jun 2019 11:54:42 +0200
> > Christophe de Dinechin wrote:
> >
> >> That is true irrespective of
On Fri, 14 Jun 2019 11:54:42 +0200
Christophe de Dinechin wrote:
> > On 13 Jun 2019, at 18:35, Alex Williamson
> > wrote:
> >
> > On Thu, 13 Jun 2019 18:17:53 +0200
> > Christophe de Dinechin wrote:
> >
> >>> On 24 May 2019, at 01:20
On Thu, 13 Jun 2019 18:17:53 +0200
Christophe de Dinechin wrote:
> > On 24 May 2019, at 01:20, Alex Williamson
> > wrote:
> >
> > Hi,
> >
> > Currently mediated device management, much like SR-IOV VF management,
> > is largely left as an
1 - 100 of 287 matches
Mail list logo
