On 5/29/2020 4:29 AM, Alex Williamson wrote:
On Wed, 27 May 2020 09:48:22 +0100
"Dr. David Alan Gilbert" wrote:
* Yan Zhao (yan.y.z...@intel.com) wrote:
BTW, for viommu, the downtime data is as below. under the same network
condition and guest memory size, and no running dirty data/memory p
* Alex Williamson (alex.william...@redhat.com) wrote:
> On Thu, 28 May 2020 04:01:02 -0400
> Yan Zhao wrote:
>
> > > > > This is my understanding of the protocol as well, when the device is
> > > > > running, pending_bytes might drop to zero if no internal state has
> > > > > changed and may be n
On Thu, May 28, 2020 at 04:59:06PM -0600, Alex Williamson wrote:
> On Wed, 27 May 2020 09:48:22 +0100
> "Dr. David Alan Gilbert" wrote:
> > * Yan Zhao (yan.y.z...@intel.com) wrote:
> > > BTW, for viommu, the downtime data is as below. under the same network
> > > condition and guest memory size, a
On Wed, 27 May 2020 09:48:22 +0100
"Dr. David Alan Gilbert" wrote:
> * Yan Zhao (yan.y.z...@intel.com) wrote:
> > BTW, for viommu, the downtime data is as below. under the same network
> > condition and guest memory size, and no running dirty data/memory produced
> > by device.
> > (1) viommu off
On Thu, 28 May 2020 04:01:02 -0400
Yan Zhao wrote:
> > > > This is my understanding of the protocol as well, when the device is
> > > > running, pending_bytes might drop to zero if no internal state has
> > > > changed and may be non-zero on the next iteration due to device
> > > > activity. Whe
> > > This is my understanding of the protocol as well, when the device is
> > > running, pending_bytes might drop to zero if no internal state has
> > > changed and may be non-zero on the next iteration due to device
> > > activity. When the device is not running, pending_bytes reporting zero
> >
* Yan Zhao (yan.y.z...@intel.com) wrote:
> On Tue, May 26, 2020 at 02:19:39PM -0600, Alex Williamson wrote:
> > On Mon, 25 May 2020 18:50:54 +0530
> > Kirti Wankhede wrote:
> >
> > > On 5/25/2020 12:29 PM, Yan Zhao wrote:
> > > > On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
On Tue, May 26, 2020 at 02:19:39PM -0600, Alex Williamson wrote:
> On Mon, 25 May 2020 18:50:54 +0530
> Kirti Wankhede wrote:
>
> > On 5/25/2020 12:29 PM, Yan Zhao wrote:
> > > On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
> > >> Hi folks,
> > >>
> > >> My impression is that
On Mon, 25 May 2020 18:50:54 +0530
Kirti Wankhede wrote:
> On 5/25/2020 12:29 PM, Yan Zhao wrote:
> > On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
> >> Hi folks,
> >>
> >> My impression is that we're getting pretty close to a workable
> >> implementation here with v22 plus r
On 5/25/2020 12:29 PM, Yan Zhao wrote:
On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
Hi folks,
My impression is that we're getting pretty close to a workable
implementation here with v22 plus respins of patches 5, 6, and 8. We
also have a matching QEMU series and a propos
On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
> Hi folks,
>
> My impression is that we're getting pretty close to a workable
> implementation here with v22 plus respins of patches 5, 6, and 8. We
> also have a matching QEMU series and a proposal for a new i40e
> consumer, as we
On 5/21/2020 12:34 PM, Yan Zhao wrote:
On Thu, May 21, 2020 at 12:39:48PM +0530, Kirti Wankhede wrote:
On 5/21/2020 10:38 AM, Yan Zhao wrote:
On Wed, May 20, 2020 at 10:46:12AM -0600, Alex Williamson wrote:
On Wed, 20 May 2020 19:10:07 +0530
Kirti Wankhede wrote:
On 5/20/2020 8:25 AM,
On 5/21/2020 12:34 PM, Yan Zhao wrote:
On Thu, May 21, 2020 at 12:39:48PM +0530, Kirti Wankhede wrote:
On 5/21/2020 10:38 AM, Yan Zhao wrote:
On Wed, May 20, 2020 at 10:46:12AM -0600, Alex Williamson wrote:
On Wed, 20 May 2020 19:10:07 +0530
Kirti Wankhede wrote:
On 5/20/2020 8:25 AM,
On Thu, May 21, 2020 at 12:39:48PM +0530, Kirti Wankhede wrote:
>
>
> On 5/21/2020 10:38 AM, Yan Zhao wrote:
> > On Wed, May 20, 2020 at 10:46:12AM -0600, Alex Williamson wrote:
> > > On Wed, 20 May 2020 19:10:07 +0530
> > > Kirti Wankhede wrote:
> > >
> > > > On 5/20/2020 8:25 AM, Yan Zhao wro
On 5/21/2020 10:38 AM, Yan Zhao wrote:
On Wed, May 20, 2020 at 10:46:12AM -0600, Alex Williamson wrote:
On Wed, 20 May 2020 19:10:07 +0530
Kirti Wankhede wrote:
On 5/20/2020 8:25 AM, Yan Zhao wrote:
On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
Hi folks,
My impression
On Wed, May 20, 2020 at 10:46:12AM -0600, Alex Williamson wrote:
> On Wed, 20 May 2020 19:10:07 +0530
> Kirti Wankhede wrote:
>
> > On 5/20/2020 8:25 AM, Yan Zhao wrote:
> > > On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
> > >> Hi folks,
> > >>
> > >> My impression is that w
On Wed, 20 May 2020 19:10:07 +0530
Kirti Wankhede wrote:
> On 5/20/2020 8:25 AM, Yan Zhao wrote:
> > On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
> >> Hi folks,
> >>
> >> My impression is that we're getting pretty close to a workable
> >> implementation here with v22 plus re
On 5/20/2020 8:25 AM, Yan Zhao wrote:
On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
Hi folks,
My impression is that we're getting pretty close to a workable
implementation here with v22 plus respins of patches 5, 6, and 8. We
also have a matching QEMU series and a proposa
On Tue, May 19, 2020 at 10:58:04AM -0600, Alex Williamson wrote:
> Hi folks,
>
> My impression is that we're getting pretty close to a workable
> implementation here with v22 plus respins of patches 5, 6, and 8. We
> also have a matching QEMU series and a proposal for a new i40e
> consumer, as we
Hi folks,
My impression is that we're getting pretty close to a workable
implementation here with v22 plus respins of patches 5, 6, and 8. We
also have a matching QEMU series and a proposal for a new i40e
consumer, as well as I assume GVT-g updates happening internally at
Intel. I expect all of
Hi,
This patch set adds:
* 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 vfio_pin_pages external API has to be marked as
dirty during migration. When IOMMU capable device is present in
21 matches
Mail list logo