On Thu, 22 Oct 2020 23:11:39 +0530
Kirti Wankhede wrote:
> On 10/22/2020 10:05 PM, Alex Williamson wrote:
> > On Thu, 22 Oct 2020 16:41:55 +0530
> > Kirti Wankhede wrote:
> >
> >> VM state change handler is called on change in VM's state. Based on
> &g
On Thu, 22 Oct 2020 16:41:55 +0530
Kirti Wankhede wrote:
> VM state change handler is called on change in VM's state. Based on
> VM state, VFIO device state should be changed.
> Added read/write helper functions for migration region.
> Added function to set device_state.
>
> Signed-off-by: Kirti
On Thu, 22 Oct 2020 16:41:54 +0530
Kirti Wankhede wrote:
> Whether the VFIO device supports migration or not is decided based of
> migration region query. If migration region query is successful and migration
> region initialization is successful then migration is supported else
> migration is bl
On Thu, 22 Oct 2020 16:41:53 +0530
Kirti Wankhede wrote:
> Added functions to save and restore PCI device specific data,
> specifically config space of PCI device.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> ---
> hw/vfio/pci.c | 48
> ++
On Wed, 21 Oct 2020 17:30:04 +0800
Zenghui Yu wrote:
> On 2020/9/25 6:49, Alex Williamson wrote:
> >> +} else if (interrupt_type == VFIO_INT_MSIX) {
> >> +uint16_t offset;
> >> +
> >> +msix_load(pdev, f);
> >>
On Wed, 21 Oct 2020 09:37:53 +0200
Paolo Bonzini wrote:
> On 21/10/20 00:44, Alex Williamson wrote:
> > Do we necessarily need a memory map ioctl for this or could it be the
> > QEMU code that compares the old and new maps to trigger map and unmap
> > ioctls? For example (a
On Tue, 20 Oct 2020 11:24:58 +0200
Paolo Bonzini wrote:
> On 19/10/20 21:02, Alex Williamson wrote:
> >> For KVM we were thinking of changing the whole
> >> memory map with a single ioctl, but that's much easier because KVM
> >> builds its page tables lazily.
On Tue, 20 Oct 2020 00:45:28 +0530
Kirti Wankhede wrote:
> On 10/19/2020 10:54 PM, Alex Williamson wrote:
> > On Mon, 19 Oct 2020 11:31:03 +0530
> > Kirti Wankhede wrote:
> >
> >> On 9/26/2020 3:53 AM, Alex Williamson wrote:
> >>> On Wed, 23 Se
On Fri, 16 Oct 2020 13:42:29 +0200
Paolo Bonzini wrote:
> On 16/10/20 13:29, FelixCuioc wrote:
> > The issue here is that an assinged EHCI device accesses
> > an adjacent mapping between the delete and add phases
> > of the VFIO MemoryListener.
> > We want to skip flatview_simplify() is to preven
On Sun, 18 Oct 2020 02:05:03 +0530
Kirti Wankhede wrote:
> On 9/26/2020 1:50 AM, Alex Williamson wrote:
> > On Wed, 23 Sep 2020 04:54:08 +0530
> > Kirti Wankhede wrote:
> >
> >> Added migration state change notifier to get notification on migration
> >&
On Sun, 18 Oct 2020 23:13:39 +0530
Kirti Wankhede wrote:
>
>
> +vfio_migration_set_state(char *name, uint32_t state) " (%s) state %d"
> +vfio_vmstate_change(char *name, int running, const char *reason,
> uint32_t dev_state) " (%s) running %d reason %s device state %d"
> dif
On Mon, 19 Oct 2020 11:31:03 +0530
Kirti Wankhede wrote:
> On 9/26/2020 3:53 AM, Alex Williamson wrote:
> > On Wed, 23 Sep 2020 04:54:15 +0530
> > Kirti Wankhede wrote:
> >
> >> Create mapped iova list when vIOMMU is enabled. For each mapped iova
> >&g
On Mon, 19 Oct 2020 13:32:17 +
Zhengui li wrote:
> fix incorrect print type.
Why is it incorrect, describe your change. Patches must include a
Signed-off-by to adhere to the developer's certificate of origin.
Thanks,
Alex
> ---
> hw/vfio/common.c | 4 ++--
> 1 file changed, 2 insertions(
On Sun, 18 Oct 2020 02:00:44 +0530
Kirti Wankhede wrote:
> On 9/26/2020 1:50 AM, Alex Williamson wrote:
> > On Wed, 23 Sep 2020 04:54:07 +0530
> > Kirti Wankhede wrote:
> >
> >> VM state change handler gets called on change in VM's state. This is used
&g
On Thu, 8 Oct 2020 12:32:35 -0400
Steven Sistare wrote:
> On 8/24/2020 6:30 PM, Alex Williamson wrote:
> > On Wed, 19 Aug 2020 17:52:26 -0400
> > Steven Sistare wrote:
> >> On 8/17/2020 10:42 PM, Alex Williamson wrote:
> >>> On Mon, 17 Aug 2020 15:44:0
On Fri, 9 Oct 2020 17:18:15 +0100
Stefan Hajnoczi wrote:
> Device emulation
>
> Device resources
>
> Devices provide resources that drivers interact with such as hardware
> registers, memory, or interrupts. The fundamental requirement of
> out-of-process device e
&err);
> +if (ret) {
> +g_free(giommu);
> +goto fail;
> +}
> +
> ret = memory_region_register_iommu_notifier(section->mr, &giommu->n,
> &err);
> if (ret) {
Acked-by: Alex Williamson
t in
unmap calls that attempt to bisect a mapping that spans both ranges.
Both unmap calls would fail in that case. I think we could solve this
more completely with a high water marker, but this probably good enough
for now.
Acked-by: Alex Williamson
There are definitely resource allocation issues on the host in the
crashing case. The quirks currently enumerate the device BARs without
testing them, we identify a device and know what the resources should
be, which is why I think QEMU crashes. Are you able to test if the
patch below is sufficie
non-mangled patch
** Patch added: "patch for test"
https://bugs.launchpad.net/qemu/+bug/1897481/+attachment/5415693/+files/test-bar-size.diff
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1897481
Please attach output from `dmesg` and `sudo lspci -vvv`, both from the
host. Laptops typically don't provide sufficient resources for GPUs
attached like this, so my guess is that we're trying to add a quirk on
top of a BAR that isn't mapped. If that's the case, the following host
kernel options m
On Mon, 28 Sep 2020 15:05:05 -0500
Wei Huang wrote:
> Add support to sync the IOVA-to-GPA translation at the time of IOMMU
> page invalidation. This function is called when two IOMMU commands,
> AMDVI_CMD_INVAL_AMDVI_PAGES and AMDVI_CMD_INVAL_AMDVI_ALL, are
> intercepted. Address space notifiers
On Tue, 29 Sep 2020 09:27:02 +0100
Stefan Hajnoczi wrote:
> On Fri, May 29, 2020 at 02:00:46AM +0530, Kirti Wankhede wrote:
> > * IOCTL VFIO_IOMMU_DIRTY_PAGES to get dirty pages bitmap with
> > respect to IOMMU container rather than per device. All pages pinned by
> > vendor driver through vf
On Wed, 23 Sep 2020 04:54:19 +0530
Kirti Wankhede wrote:
> Added amount of bytes transferred to the target VM by all VFIO devices
>
> Signed-off-by: Kirti Wankhede
> ---
>
> Note: Comments from v25 for this patch are not addressed yet.
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg71
On Wed, 23 Sep 2020 04:54:15 +0530
Kirti Wankhede wrote:
> Create mapped iova list when vIOMMU is enabled. For each mapped iova
> save translated address. Add node to list on MAP and remove node from
> list on UNMAP.
> This list is used to track dirty pages during migration.
>
> Signed-off-by: K
On Wed, 23 Sep 2020 04:54:07 +0530
Kirti Wankhede wrote:
> VM state change handler gets called on change in VM's state. This is used to
> set
> VFIO device state to _RUNNING.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> Reviewed-by: Dr. David Alan Gilbert
> ---
> hw/vfio/migra
On Wed, 23 Sep 2020 04:54:09 +0530
Kirti Wankhede wrote:
> Define flags to be used as delimeter in migration file stream.
> Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
> region from these functions at source during saving or pre-copy phase.
> Set VFIO device state d
On Wed, 23 Sep 2020 04:54:14 +0530
Kirti Wankhede wrote:
> Call VFIO_IOMMU_DIRTY_PAGES ioctl to start and stop dirty pages tracking
> for VFIO devices.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Dr. David Alan Gilbert
> ---
> hw/vfio/migration.c | 36
On Wed, 23 Sep 2020 04:54:08 +0530
Kirti Wankhede wrote:
> Added migration state change notifier to get notification on migration state
> change. These states are translated to VFIO device state and conveyed to
> vendor
> driver.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> Revi
On Wed, 23 Sep 2020 04:54:10 +0530
Kirti Wankhede wrote:
> Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
> functions. These functions handles pre-copy and stop-and-copy phase.
>
> In _SAVING|_RUNNING device state or pre-copy phase:
> - read pending_bytes. If pendin
On Wed, 23 Sep 2020 04:54:06 +0530
Kirti Wankhede wrote:
> Whether the VFIO device supports migration or not is decided based of
> migration region query. If migration region query is successful and migration
> region initialization is successful then migration is supported else
> migration is bl
On Wed, 23 Sep 2020 04:54:05 +0530
Kirti Wankhede wrote:
> These functions save and restore PCI device specific data - config
> space of PCI device.
> Used VMStateDescription to save and restore interrupt state.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> ---
> hw/vfio/pci.c
The device ID on function 7 is 0x which is typically not valid,
there's no entry for it in the PCI IDs database. Someone from Chelsio
would need to explain why it's even exposed, but there doesn't seem to
be any value in quirking it since it provides no useful function.
** Changed in: qemu
I don't understand the purpose of function 7 on these cards, the class
code indicates an Ethernet device, but without any BARs, I very much
doubt that the functions provide any useful service. Config space is
invalid for the function as QEMU identifies, the referenced BAR resource
for the MSI-X ve
PS, this can never be true:
+ (vdev->device_id & 0xff00) == 0x1425))
The lower byte would always be 00. It's the wrong fix anyway, BAR4 is
still missing.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bu
There are no BAR resources for this device:
83:00.7 Ethernet controller [0200]: Chelsio Communications Inc Device
[1425:]
Subsystem: Chelsio Communications Inc Device [1425:]
Physical Slot: 818
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+
St
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-l...@redhat.com
On Mon, 14 Sep 2020 11:37:03 +0100
Stefan Hajnoczi wrote:
> On Wed, Sep 09, 2020 at 02:51:50PM +0200, Philippe Mathieu-Daudé wrote:
> > On 9/7/20 1:16 PM, Stefan Hajnoczi wrote:
> > > Development of the userspace NVMe block driver picked up again recently.
> > > After talking with Fam I am step
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, 10 Sep 2020 17:29:25 +0200
Philippe Mathieu-Daudé wrote:
> Hi Stefan, Alex.
>
> On 9/10/20 12:44 PM, Stefan Hajnoczi wrote:
> > On Wed, Sep 09, 2020 at 04:23:53PM +0200, Philippe Mathieu-Daudé wrote:
> >> +/**
> >> + * Initialize device MSIX IRQs and register event notifiers.
> >> + *
On Wed, 19 Aug 2020 17:52:26 -0400
Steven Sistare wrote:
> On 8/17/2020 10:42 PM, Alex Williamson wrote:
> > On Mon, 17 Aug 2020 15:44:03 -0600
> > Alex Williamson wrote:
> >
> >> On Mon, 17 Aug 2020 17:20:57 -0400
> >> Steven Sistare wrote:
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, Dani
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 Wed, 19 Aug 2020 18:03:17 +0200
Philippe Mathieu-Daudé wrote:
> qemu_vfio_pci_init_irq() allows us to initialize any type of IRQ,
> but only one. Introduce qemu_vfio_pci_init_msix_irqs() which is
> specific to MSIX IRQ type, and allow us to use multiple IRQs
> (thus passing multiple eventfd no
On Tue, 18 Aug 2020 18:45:08 +0200
Philippe Mathieu-Daudé wrote:
> qemu_vfio_pci_init_irq() allows us to initialize any type of IRQ,
> but only one. Introduce qemu_vfio_pci_init_msix_irqs() which is
> specific to MSIX IRQ type, and allow us to use multiple IRQs
> (thus passing multiple eventfd no
On Tue, 18 Aug 2020 18:45:06 +0200
Philippe Mathieu-Daudé wrote:
> The vfio-helpers implementation expects a TYPEv1 IOMMU, see
> qemu_vfio_init_pci:
>
> 263 if (!ioctl(s->container, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU)) {
> 264 error_setg_errno(errp, errno, "VFIO IOMMU check f
On Mon, 17 Aug 2020 15:44:03 -0600
Alex Williamson wrote:
> On Mon, 17 Aug 2020 17:20:57 -0400
> Steven Sistare wrote:
>
> > On 8/17/2020 4:48 PM, Alex Williamson wrote:
> > > On Mon, 17 Aug 2020 14:30:51 -0400
> > > Steven Sistare wrote:
> > >
On Mon, 17 Aug 2020 17:20:57 -0400
Steven Sistare wrote:
> On 8/17/2020 4:48 PM, Alex Williamson wrote:
> > On Mon, 17 Aug 2020 14:30:51 -0400
> > Steven Sistare wrote:
> >
> >> On 7/30/2020 11:14 AM, Steve Sistare wrote:
> >>> Anonymous memor
On Mon, 17 Aug 2020 14:30:51 -0400
Steven Sistare wrote:
> On 7/30/2020 11:14 AM, Steve Sistare wrote:
> > Anonymous memory segments used by the guest are preserved across a re-exec
> > of qemu, mapped at the same VA, via a proposed madvise(MADV_DOEXEC) option
> > in the Linux kernel. For the mad
On Thu, 13 Aug 2020 19:29:57 +0200
Philippe Mathieu-Daudé wrote:
> Now that our helper is ready for handling multiple IRQs, let
> qemu_vfio_open_pci() take an 'irq_count' argument.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
As with patch 2/ tying IRQ setup with the opening of a device see
On Thu, 13 Aug 2020 19:29:54 +0200
Philippe Mathieu-Daudé wrote:
> As we want to use more than one single IRQ, add a check that
> the device accept our request to use multiple IRQs.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> util/vfio-helpers.c | 6 ++
> util/trace-events | 1 +
>
On Thu, 13 Aug 2020 19:29:56 +0200
Philippe Mathieu-Daudé wrote:
> Let qemu_vfio_pci_init_irq() take an 'index' argument, so we can
> set the EventNotifier to a specific IRQ.
> Add a safety check. Since our helper is limited to one single IRQ
> we are safe.
>
> Our only user is the NVMe block dr
On Thu, 13 Aug 2020 19:29:52 +0200
Philippe Mathieu-Daudé wrote:
> Once opened, we will used the same IRQ type for all our event
> notifiers, so pass the argument when we open the PCI device,
> store the IRQ type in the driver state, and directly use the
> value saved in the state each time we ca
On Thu, 13 Aug 2020 20:02:45 +0200
Auger Eric wrote:
> Hi Alex,
>
> On 8/13/20 6:59 PM, Alex Williamson wrote:
> > On Thu, 13 Aug 2020 15:37:08 +0800
> > Chen Qun wrote:
> >
> >> Clang static code analyzer show warning:
> >> hw/vfio/platform.c:2
ear(intp->interrupt);
> ^ ~~
>
> Reported-by: Euler Robot
> Signed-off-by: Chen Qun
> ---
> Cc: Alex Williamson
> Cc: Eric Auger
> ---
> hw/vfio/platform.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/vfio/platform.c b/hw/vfio/platfo
On Tue, 11 Aug 2020 19:28:45 +0200
Philippe Mathieu-Daudé wrote:
> Add a new 'index' argument to qemu_vfio_pci_init_irq() to be able
> to initialize other IRQs than IRQ #0. Adapt the single user of this
> API in nvme_init().
This is actually addressing the what the vfio uAPI refers to as the
sub
On Tue, 11 Aug 2020 19:28:44 +0200
Philippe Mathieu-Daudé wrote:
> Add a trace event to display the amount of IRQs available
> on the device.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> util/vfio-helpers.c | 1 +
> util/trace-events | 1 +
> 2 files changed, 2 insertions(+)
>
> diff -
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 Thu, 16 Jul 2020 08:31:43 -0700
Thanos Makatos wrote:
> This patch introduces the VFIO-over-socket protocol specification, which
> is designed to allow devices to be emulated outside QEMU, in a separate
> process. VFIO-over-socket reuses the existing VFIO defines, structs and
> concepts.
>
>
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 Tue, 28 Jul 2020 11:33:55 +0200
Niklas Schnelle wrote:
> On 7/27/20 6:47 PM, Alex Williamson wrote:
> > On Mon, 27 Jul 2020 17:40:39 +0200
> > Pierre Morel wrote:
> >
> >> On 2020-07-23 18:29, Alex Williamson wrote:
> >>> On Thu, 23 Jul 2020
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, curre
On Mon, 27 Jul 2020 17:40:39 +0200
Pierre Morel wrote:
> On 2020-07-23 18:29, Alex Williamson wrote:
> > On Thu, 23 Jul 2020 11:13:55 -0400
> > Matthew Rosato wrote:
> >
> >> I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
> >&
On Thu, 23 Jul 2020 11:13:55 -0400
Matthew Rosato wrote:
> I noticed that after kernel commit abafbc55 'vfio-pci: Invalidate mmaps
> and block MMIO access on disabled memory' vfio-pci via qemu on s390x
> fails spectacularly, with errors in qemu like:
>
> qemu-system-s390x: vfio_region_read(0001:
On Tue, 21 Jul 2020 10:43:21 +0800
Xiang Zheng wrote:
> Hi Kirti,
>
> Sorry to disturb you since this patch set has been merged, and I cannot
> receive the qemu-side emails about this patch set.
>
> We are going to support migration for VFIO devices which support dirty
> pages tracking.
>
> An
On Wed, 15 Jul 2020 15:13:22 +0200
Philippe Mathieu-Daudé wrote:
> These devices do not depend on the target CPU configuration
> (32 or 64-bit, big / little endian). Move them to common-obj
> to compile them once for all the targets.
>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> hw/vfio/Ma
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 Fri, 17 Jul 2020 16:57:40 +0100
Peter Maydell wrote:
> On Fri, 17 Jul 2020 at 16:54, Alex Williamson
> wrote:
> >
> > On Thu, 16 Jul 2020 18:46:33 +0100
> > Peter Maydell wrote:
> >
> > > Alex (Williamson) -- as the vfio maintainer, do you have a vie
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 openstac
@@ -264,8 +265,15 @@ static uint64_t vfio_ati_3c3_quirk_read(void *opaque,
> > return data;
> > }
> >
> > +static void vfio_ati_3c3_quirk_write(void *opaque, hwaddr addr,
> > +uint64_t data, unsigned size)
> > +{
> > +
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:29:57AM +0800, Yan Zhao
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
fb_display_update()
then replaces and frees dpy->con->surface with dpy->ramfb->ds, that's
where the object point to by dpy->region.surface was freed. Right?
If so, looks ok to me. If you're constructing a pull request, I'll
give you an:
Acked-by: Alex Williamson
Reviewed-by: Alex Williamson
If you need me to send a pull, let me know. Thanks,
Alex
> When you say "qemu has no support", do you actually mean "qemu people
> are unable to help you if you break things by bypassing the in-place
> restrictions", or "qemu is designed to not work when restrictions are
> bypassed"?
The former. There are two aspects to this. The first is that the
dev
On Tue, 7 Jul 2020 10:38:01 +
Felipe Franciosi wrote:
> > On Jul 6, 2020, at 3:20 PM, Alex Williamson
> > wrote:
> >
> > On Mon, 6 Jul 2020 10:55:00 +
> > Thanos Makatos wrote:
> >
> >> We have an issue when using the VFIO-ov
On Mon, 6 Jul 2020 10:55:00 +
Thanos Makatos wrote:
> We have an issue when using the VFIO-over-socket libmuser PoC
> (https://www.mail-archive.com/qemu-devel@nongnu.org/msg692251.html) instead of
> the VFIO kernel module: we notice that DMA regions used by the emulated device
> can be abrupt
You'd need to create a 160KB VM in order to stay below the required direct map
memory regions imposed by the system firmware (e8000 - c). Non-upstream
bypasses of those restrictions are clearly not supported. You can find more
details regarding the RMRR restriction here:
https://access.red
On Fri, 26 Jun 2020 13:16:13 +0100
"Dr. David Alan Gilbert" wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > On Wed, 24 Jun 2020 19:59:39 +0530
> > Kirti Wankhede wrote:
> >
> > > On 6/23/2020 1:58 AM, Alex Williamson wrote:
&g
On Thu, 25 Jun 2020 20:31:12 +0530
Kirti Wankhede wrote:
> On 6/25/2020 12:26 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:24 +0530
> > Kirti Wankhede wrote:
> >
> >> With vIOMMU, IO virtual address range can get unmapped while in pre-copy
> &g
On Thu, 25 Jun 2020 20:13:39 +0530
Kirti Wankhede wrote:
> On 6/25/2020 12:25 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:23 +0530
> > Kirti Wankhede wrote:
> >
> >> vfio_listener_log_sync gets list of dirty pages from container using
> >>
On Thu, 25 Jun 2020 20:04:08 +0530
Kirti Wankhede wrote:
> On 6/25/2020 12:25 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:22 +0530
> > Kirti Wankhede wrote:
> >
> >> Create mapped iova list when vIOMMU is enabled. For each mapped iova
> >&g
On Thu, 25 Jun 2020 19:46:22 +0530
Kirti Wankhede wrote:
> On 6/25/2020 12:24 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:18 +0530
> > Kirti Wankhede wrote:
> >
> >> Sequence during _RESUMING device state:
> >> While data for this device i
On Thu, 25 Jun 2020 19:39:08 +0530
Kirti Wankhede wrote:
> On 6/25/2020 12:25 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:20 +0530
> > Kirti Wankhede wrote:
> >
> >> Added helper functions to get IOMMU info capability chain.
> >> Add
On Wed, 24 Jun 2020 19:59:39 +0530
Kirti Wankhede wrote:
> On 6/23/2020 1:58 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:12 +0530
> > Kirti Wankhede wrote:
> >
> >> These functions save and restore PCI device specific data - config
> >> sp
On Sun, 21 Jun 2020 01:51:21 +0530
Kirti Wankhede wrote:
> Call VFIO_IOMMU_DIRTY_PAGES ioctl to start and stop dirty pages tracking
> for VFIO devices.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Dr. David Alan Gilbert
> ---
> hw/vfio/migration.c | 36
On Sun, 21 Jun 2020 01:51:18 +0530
Kirti Wankhede wrote:
> Sequence during _RESUMING device state:
> While data for this device is available, repeat below steps:
> a. read data_offset from where user application should write data.
> b. write data of data_size to migration region from data_offset
ddresses and report those dirty.
>
> Suggested-by: Alex Williamson
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> ---
> hw/vfio/common.c | 85
> +---
> 1 file changed, 81 insertions(+), 4 deletions(-)
>
&g
On Sun, 21 Jun 2020 01:51:23 +0530
Kirti Wankhede wrote:
> vfio_listener_log_sync gets list of dirty pages from container using
> VFIO_IOMMU_GET_DIRTY_BITMAP ioctl and mark those pages dirty when all
> devices are stopped and saving state.
> Return early for the RAM block section of mapped MMIO r
On Sun, 21 Jun 2020 01:51:20 +0530
Kirti Wankhede wrote:
> Added helper functions to get IOMMU info capability chain.
> Added function to get migration capability information from that
> capability chain for IOMMU container.
>
> Similar change was proposed earlier:
> https://lists.gnu.org/archiv
On Sun, 21 Jun 2020 01:51:22 +0530
Kirti Wankhede wrote:
> Create mapped iova list when vIOMMU is enabled. For each mapped iova
> save translated address. Add node to list on MAP and remove node from
> list on UNMAP.
> This list is used to track dirty pages during migration.
This seems like a lo
On Wed, 24 Jun 2020 02:04:24 +0530
Kirti Wankhede wrote:
> On 6/23/2020 4:20 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:17 +0530
> > Kirti Wankhede wrote:
> >
> >> Added .save_live_pending, .save_live_iterate and
> >> .save_live_complete_
On Wed, 24 Jun 2020 00:51:06 +0530
Kirti Wankhede wrote:
> On 6/23/2020 4:20 AM, Alex Williamson wrote:
> > On Sun, 21 Jun 2020 01:51:16 +0530
> > Kirti Wankhede wrote:
> >
> >> Define flags to be used as delimeter in migration file stream.
> >> Added
On Sun, 21 Jun 2020 01:51:16 +0530
Kirti Wankhede wrote:
> Define flags to be used as delimeter in migration file stream.
> Added .save_setup and .save_cleanup functions. Mapped & unmapped migration
> region from these functions at source during saving or pre-copy phase.
> Set VFIO device state d
On Sun, 21 Jun 2020 01:51:17 +0530
Kirti Wankhede wrote:
> Added .save_live_pending, .save_live_iterate and .save_live_complete_precopy
> functions. These functions handles pre-copy and stop-and-copy phase.
>
> In _SAVING|_RUNNING device state or pre-copy phase:
> - read pending_bytes. If pendin
On Sun, 21 Jun 2020 01:51:14 +0530
Kirti Wankhede wrote:
> VM state change handler gets called on change in VM's state. This is used to
> set
> VFIO device state to _RUNNING.
>
> Signed-off-by: Kirti Wankhede
> Reviewed-by: Neo Jia
> Reviewed-by: Dr. David Alan Gilbert
> ---
> hw/vfio/migra
701 - 800 of 4487 matches
Mail list logo
