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:
> >
> > > > From: Alex Williamson
> 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:
>
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Wednesday, August 22, 2018 10:08 AM
> > >
> > > On
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:
> >
> > > > From: Wang, Zhi A
> > > > Sent: Wednesday,
> 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:
>
> > > From: Wang, Zhi A
> > > Sent: Wednesday, August 22, 2018 2:43 AM
> > > >
> > > > Are there any suggestions how we can
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
> 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 virtual device model living within the kernel seems
> > troublesome. If
On 08/21/18 07:08, Alex Williamson wrote:
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
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
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 version and a minimum required version
"Match of versions" in
Hi Alex and Kirti:
Thanks for your reply and discussion. :) Sorry for my late reply since
there quite some work and email needs to be caught up after my vacation.
From my point of view, failing the migration because of the mismatch
of version in different levels provides different
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 is clearer to me now. I didn't
> >> realize that you also
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 is clearer to me now. I didn't
>> realize that you also want to support cross hardware migration. Well, I
>> thought for a
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 vGPU case but
could be quite popular in other mdev cases.
Let me
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 be supported in VFIO, a scheme
> >> of deciding if a mdev
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 be supported in VFIO, a scheme of
deciding if a mdev could be migratable between the source machine and the
destination machine is
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
>
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
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_type is:
There are several pre-defined mdev_types with different
Hi Erik:
Thanks for the reply and also the detailed guide. :) I can understand
your idea is a comprehensive and generic approach for matching and
checking all kinds of "hostdev"s in libvirt, not only mdev-specific one
since mdev is a sub-hierarchy of "hostdev". If you idea become true,
mdev
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
On Sun, Jul 29, 2018 at 09:19:41PM +, 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
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 discuss a
possible solution which needs fewer modifications of
22 matches
Mail list logo
