From: "Lan, Tianyu" <tianyu.lan@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
"Dong, Eddie" <eddie.dong@intel.com>,
"a.motakis@virtualopensystems.com"
<a.motakis@virtualopensystems.com>,
Alex Williamson <alex.williamson@redhat.com>,
"b.reynal@virtualopensystems.com"
<b.reynal@virtualopensystems.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"Wyborny, Carolyn" <carolyn.wyborny@intel.com>,
"Skidmore, Donald C" <donald.c.skidmore@intel.com>,
"Jani, Nrupal" <nrupal.jani@intel.com>,
Alexander Graf <agraf@suse.de>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"Tantilov, Emil S" <emil.s.tantilov@intel.com>,
Or Gerlitz <gerlitz.or@gmail.com>,
"Rustad, Mark D" <mark.d.rustad@intel.com>,
Eric Auger <eric.auger@linaro.org>,
intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
"Ronciak, John" <john.ronciak@intel.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Williams, Mitch A" <mitch.a.williams@intel.com>,
Netdev <netdev@vger.kernel.org>,
"Nelson, Shannon" <shannon.nelson@intel.com>,
Wei Yang <weiyang@linux.vnet.ibm.com>,
"zajec5@gmail.com" <zajec5@gmail.com>
Subject: Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC
Date: Wed, 9 Dec 2015 19:19:15 +0800 [thread overview]
Message-ID: <56680E33.6040204@intel.com> (raw)
In-Reply-To: <20151209122831-mutt-send-email-mst@redhat.com>
On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote:
> On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote:
>> Hi Michael & Alexander:
>> Thanks a lot for your comments and suggestions.
>
> It's nice that it's appreciated, but you then go on and ignore
> all that I have written here:
> https://www.mail-archive.com/kvm@vger.kernel.org/msg123826.html
>
No, I will reply it separately and according your suggestion to snip it
into 3 thread.
>> We still need to support Windows guest for migration and this is why our
>> patches keep all changes in the driver since it's impossible to change
>> Windows kernel.
>
> This is not a reasonable argument. It makes no sense to duplicate code
> on Linux because you must duplicate code on Windows. Let's assume you
> must do it in the driver on windows because windows has closed source
> drivers. What does it matter? Linux can still do it as part of DMA API
> and have it apply to all drivers.
>
Sure. Duplicated code should be encapsulated and make it able to reuse
by other drivers. Just like you said the dummy write part.
I meant the framework should not require to change Windows kernel code
(such as PM core or PCI bus driver)and this will block implementation on
the Windows.
I think it's not problem to duplicate code in the Windows drivers.
>> Following is my idea to do DMA tracking.
>>
>> Inject event to VF driver after memory iterate stage
>> and before stop VCPU and then VF driver marks dirty all
>> using DMA memory. The new allocated pages also need to
>> be marked dirty before stopping VCPU. All dirty memory
>> in this time slot will be migrated until stop-and-copy
>> stage. We also need to make sure to disable VF via clearing the
>> bus master enable bit for VF before migrating these memory.
>>
>> The dma page allocated by VF driver also needs to reserve space
>> to do dummy write.
>
> I suggested ways to do it all in the hypervisor without driver hacks, or
> hide it within DMA API without need to reserve extra space. Both
> approaches seem much cleaner.
>
This sounds reasonable. We may discuss it detail in the separate thread.
WARNING: multiple messages have this Message-ID (diff)
From: "Lan, Tianyu" <tianyu.lan@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Wei Yang <weiyang@linux.vnet.ibm.com>,
"Tantilov, Emil S" <emil.s.tantilov@intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Alexander Duyck <alexander.duyck@gmail.com>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
"Rustad, Mark D" <mark.d.rustad@intel.com>,
"Wyborny, Carolyn" <carolyn.wyborny@intel.com>,
Eric Auger <eric.auger@linaro.org>,
"Skidmore, Donald C" <donald.c.skidmore@intel.com>,
"zajec5@gmail.com" <zajec5@gmail.com>,
Alexander Graf <agraf@suse.de>,
intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
"Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com>,
Or Gerlitz <gerlitz.or@gmail.com>,
"Williams, Mitch A" <mitch.a.williams@intel.com>,
"Jani, Nrupal" <nrupal.jani@intel.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"a.motakis@virtualopensystems.com"
<a.motakis@virtualopensystems.com>,
"b.reynal@virtualopensystems.com"
<b.reynal@virtualopensystems.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"Nelson, Shannon" <shannon.nelson@intel.com>,
"Dong, Eddie" <eddie.dong@intel.com>,
Alex Williamson <alex.williamson@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Ronciak, John" <john.ronciak@intel.com>,
Netdev <netdev@vger.kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC
Date: Wed, 9 Dec 2015 19:19:15 +0800 [thread overview]
Message-ID: <56680E33.6040204@intel.com> (raw)
In-Reply-To: <20151209122831-mutt-send-email-mst@redhat.com>
On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote:
> On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote:
>> Hi Michael & Alexander:
>> Thanks a lot for your comments and suggestions.
>
> It's nice that it's appreciated, but you then go on and ignore
> all that I have written here:
> https://www.mail-archive.com/kvm@vger.kernel.org/msg123826.html
>
No, I will reply it separately and according your suggestion to snip it
into 3 thread.
>> We still need to support Windows guest for migration and this is why our
>> patches keep all changes in the driver since it's impossible to change
>> Windows kernel.
>
> This is not a reasonable argument. It makes no sense to duplicate code
> on Linux because you must duplicate code on Windows. Let's assume you
> must do it in the driver on windows because windows has closed source
> drivers. What does it matter? Linux can still do it as part of DMA API
> and have it apply to all drivers.
>
Sure. Duplicated code should be encapsulated and make it able to reuse
by other drivers. Just like you said the dummy write part.
I meant the framework should not require to change Windows kernel code
(such as PM core or PCI bus driver)and this will block implementation on
the Windows.
I think it's not problem to duplicate code in the Windows drivers.
>> Following is my idea to do DMA tracking.
>>
>> Inject event to VF driver after memory iterate stage
>> and before stop VCPU and then VF driver marks dirty all
>> using DMA memory. The new allocated pages also need to
>> be marked dirty before stopping VCPU. All dirty memory
>> in this time slot will be migrated until stop-and-copy
>> stage. We also need to make sure to disable VF via clearing the
>> bus master enable bit for VF before migrating these memory.
>>
>> The dma page allocated by VF driver also needs to reserve space
>> to do dummy write.
>
> I suggested ways to do it all in the hypervisor without driver hacks, or
> hide it within DMA API without need to reserve extra space. Both
> approaches seem much cleaner.
>
This sounds reasonable. We may discuss it detail in the separate thread.
WARNING: multiple messages have this Message-ID (diff)
From: "Lan, Tianyu" <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Alexander Duyck
<alexander.duyck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Dong,
Eddie" <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org"
<a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org"
<b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Wyborny,
Carolyn"
<carolyn.wyborny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Skidmore,
Donald C"
<donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Jani,
Nrupal" <nrupal.jani-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>,
"kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org"
<qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>,
"Tantilov,
Emil S" <emil.s.tantilov-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Rustad,
Mark D" <mark.d.rustad-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
intel-wired-lan
<intel-wired-lan-qjLDD68F18P21nG7glBr7A@public.gmane.org>,
"Kirsher,
Jeffrey T"
<jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, "
Subject: Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC
Date: Wed, 9 Dec 2015 19:19:15 +0800 [thread overview]
Message-ID: <56680E33.6040204@intel.com> (raw)
In-Reply-To: <20151209122831-mutt-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote:
> On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote:
>> Hi Michael & Alexander:
>> Thanks a lot for your comments and suggestions.
>
> It's nice that it's appreciated, but you then go on and ignore
> all that I have written here:
> https://www.mail-archive.com/kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg123826.html
>
No, I will reply it separately and according your suggestion to snip it
into 3 thread.
>> We still need to support Windows guest for migration and this is why our
>> patches keep all changes in the driver since it's impossible to change
>> Windows kernel.
>
> This is not a reasonable argument. It makes no sense to duplicate code
> on Linux because you must duplicate code on Windows. Let's assume you
> must do it in the driver on windows because windows has closed source
> drivers. What does it matter? Linux can still do it as part of DMA API
> and have it apply to all drivers.
>
Sure. Duplicated code should be encapsulated and make it able to reuse
by other drivers. Just like you said the dummy write part.
I meant the framework should not require to change Windows kernel code
(such as PM core or PCI bus driver)and this will block implementation on
the Windows.
I think it's not problem to duplicate code in the Windows drivers.
>> Following is my idea to do DMA tracking.
>>
>> Inject event to VF driver after memory iterate stage
>> and before stop VCPU and then VF driver marks dirty all
>> using DMA memory. The new allocated pages also need to
>> be marked dirty before stopping VCPU. All dirty memory
>> in this time slot will be migrated until stop-and-copy
>> stage. We also need to make sure to disable VF via clearing the
>> bus master enable bit for VF before migrating these memory.
>>
>> The dma page allocated by VF driver also needs to reserve space
>> to do dummy write.
>
> I suggested ways to do it all in the hypervisor without driver hacks, or
> hide it within DMA API without need to reserve extra space. Both
> approaches seem much cleaner.
>
This sounds reasonable. We may discuss it detail in the separate thread.
WARNING: multiple messages have this Message-ID (diff)
From: "Lan, Tianyu" <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Alexander Duyck
<alexander.duyck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Dong,
Eddie" <eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org"
<a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org"
<b.reynal-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
"Wyborny,
Carolyn"
<carolyn.wyborny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Skidmore,
Donald C"
<donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Jani,
Nrupal" <nrupal.jani-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>,
"kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
"qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org"
<qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>,
"Tantilov,
Emil S" <emil.s.tantilov-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Or Gerlitz <gerlitz.or-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"Rustad,
Mark D" <mark.d.rustad-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Eric Auger <eric.auger-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
intel-wired-lan
<intel-wired-lan-qjLDD68F18P21nG7glBr7A@public.gmane.org>,
"Kirsher,
Jeffrey T"
<jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC
Date: Wed, 9 Dec 2015 19:19:15 +0800 [thread overview]
Message-ID: <56680E33.6040204@intel.com> (raw)
In-Reply-To: <20151209122831-mutt-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote:
> On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote:
>> Hi Michael & Alexander:
>> Thanks a lot for your comments and suggestions.
>
> It's nice that it's appreciated, but you then go on and ignore
> all that I have written here:
> https://www.mail-archive.com/kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg123826.html
>
No, I will reply it separately and according your suggestion to snip it
into 3 thread.
>> We still need to support Windows guest for migration and this is why our
>> patches keep all changes in the driver since it's impossible to change
>> Windows kernel.
>
> This is not a reasonable argument. It makes no sense to duplicate code
> on Linux because you must duplicate code on Windows. Let's assume you
> must do it in the driver on windows because windows has closed source
> drivers. What does it matter? Linux can still do it as part of DMA API
> and have it apply to all drivers.
>
Sure. Duplicated code should be encapsulated and make it able to reuse
by other drivers. Just like you said the dummy write part.
I meant the framework should not require to change Windows kernel code
(such as PM core or PCI bus driver)and this will block implementation on
the Windows.
I think it's not problem to duplicate code in the Windows drivers.
>> Following is my idea to do DMA tracking.
>>
>> Inject event to VF driver after memory iterate stage
>> and before stop VCPU and then VF driver marks dirty all
>> using DMA memory. The new allocated pages also need to
>> be marked dirty before stopping VCPU. All dirty memory
>> in this time slot will be migrated until stop-and-copy
>> stage. We also need to make sure to disable VF via clearing the
>> bus master enable bit for VF before migrating these memory.
>>
>> The dma page allocated by VF driver also needs to reserve space
>> to do dummy write.
>
> I suggested ways to do it all in the hypervisor without driver hacks, or
> hide it within DMA API without need to reserve extra space. Both
> approaches seem much cleaner.
>
This sounds reasonable. We may discuss it detail in the separate thread.
WARNING: multiple messages have this Message-ID (diff)
From: Lan, Tianyu <tianyu.lan@intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC
Date: Wed, 9 Dec 2015 19:19:15 +0800 [thread overview]
Message-ID: <56680E33.6040204@intel.com> (raw)
In-Reply-To: <20151209122831-mutt-send-email-mst@redhat.com>
On 12/9/2015 6:37 PM, Michael S. Tsirkin wrote:
> On Sat, Dec 05, 2015 at 12:32:00AM +0800, Lan, Tianyu wrote:
>> Hi Michael & Alexander:
>> Thanks a lot for your comments and suggestions.
>
> It's nice that it's appreciated, but you then go on and ignore
> all that I have written here:
> https://www.mail-archive.com/kvm at vger.kernel.org/msg123826.html
>
No, I will reply it separately and according your suggestion to snip it
into 3 thread.
>> We still need to support Windows guest for migration and this is why our
>> patches keep all changes in the driver since it's impossible to change
>> Windows kernel.
>
> This is not a reasonable argument. It makes no sense to duplicate code
> on Linux because you must duplicate code on Windows. Let's assume you
> must do it in the driver on windows because windows has closed source
> drivers. What does it matter? Linux can still do it as part of DMA API
> and have it apply to all drivers.
>
Sure. Duplicated code should be encapsulated and make it able to reuse
by other drivers. Just like you said the dummy write part.
I meant the framework should not require to change Windows kernel code
(such as PM core or PCI bus driver)and this will block implementation on
the Windows.
I think it's not problem to duplicate code in the Windows drivers.
>> Following is my idea to do DMA tracking.
>>
>> Inject event to VF driver after memory iterate stage
>> and before stop VCPU and then VF driver marks dirty all
>> using DMA memory. The new allocated pages also need to
>> be marked dirty before stopping VCPU. All dirty memory
>> in this time slot will be migrated until stop-and-copy
>> stage. We also need to make sure to disable VF via clearing the
>> bus master enable bit for VF before migrating these memory.
>>
>> The dma page allocated by VF driver also needs to reserve space
>> to do dummy write.
>
> I suggested ways to do it all in the hypervisor without driver hacks, or
> hide it within DMA API without need to reserve extra space. Both
> approaches seem much cleaner.
>
This sounds reasonable. We may discuss it detail in the separate thread.
next prev parent reply other threads:[~2015-12-09 11:19 UTC|newest]
Thread overview: 173+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-24 13:38 [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC Lan Tianyu
2015-11-24 13:38 ` [Intel-wired-lan] " Lan Tianyu
2015-11-24 13:38 ` [Qemu-devel] " Lan Tianyu
2015-11-24 13:38 ` [RFC PATCH V2 1/3] VFIO: Add new ioctl cmd VFIO_GET_PCI_CAP_INFO Lan Tianyu
2015-11-24 13:38 ` [Intel-wired-lan] " Lan Tianyu
2015-11-24 13:38 ` Lan Tianyu
2015-11-24 13:38 ` [Qemu-devel] " Lan Tianyu
2015-11-24 13:38 ` [RFC PATCH V2 2/3] PCI: Add macros for faked PCI migration capability Lan Tianyu
2015-11-24 13:38 ` [Intel-wired-lan] " Lan Tianyu
2015-11-24 13:38 ` Lan Tianyu
2015-11-24 13:38 ` [Qemu-devel] " Lan Tianyu
2015-11-24 13:38 ` [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver Lan Tianyu
2015-11-24 13:38 ` [Intel-wired-lan] " Lan Tianyu
2015-11-24 13:38 ` [Qemu-devel] " Lan Tianyu
2015-11-24 21:20 ` Michael S. Tsirkin
2015-11-24 21:20 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-11-24 21:20 ` [Qemu-devel] " Michael S. Tsirkin
2015-11-25 5:39 ` Alexander Duyck
2015-11-25 5:39 ` [Intel-wired-lan] " Alexander Duyck
2015-11-25 5:39 ` Alexander Duyck
2015-11-25 5:39 ` Alexander Duyck
2015-11-25 5:39 ` [Qemu-devel] " Alexander Duyck
2015-11-25 5:39 ` Lan Tianyu
2015-11-25 5:39 ` [Intel-wired-lan] " Lan Tianyu
2015-11-25 5:39 ` Lan Tianyu
2015-11-25 5:39 ` [Qemu-devel] " Lan Tianyu
2015-11-25 12:28 ` Michael S. Tsirkin
2015-11-25 12:28 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-11-25 12:28 ` Michael S. Tsirkin
2015-11-25 12:28 ` [Qemu-devel] " Michael S. Tsirkin
2015-11-25 16:02 ` Lan, Tianyu
2015-11-25 16:02 ` [Intel-wired-lan] " Lan, Tianyu
2015-11-25 16:02 ` Lan, Tianyu
2015-11-25 16:02 ` [Qemu-devel] " Lan, Tianyu
2015-11-25 16:22 ` Michael S. Tsirkin
2015-11-25 16:22 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-11-25 16:22 ` [Qemu-devel] " Michael S. Tsirkin
2015-11-25 16:24 ` Alexander Duyck
2015-11-25 16:24 ` [Intel-wired-lan] " Alexander Duyck
2015-11-25 16:24 ` Alexander Duyck
2015-11-25 16:24 ` Alexander Duyck
2015-11-25 16:24 ` [Qemu-devel] " Alexander Duyck
2015-11-25 16:39 ` Michael S. Tsirkin
2015-11-25 16:39 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-11-25 16:39 ` Michael S. Tsirkin
2015-11-25 16:39 ` Michael S. Tsirkin
2015-11-25 16:39 ` [Qemu-devel] " Michael S. Tsirkin
2015-11-25 17:24 ` Alexander Duyck
2015-11-25 17:24 ` [Intel-wired-lan] " Alexander Duyck
2015-11-25 17:24 ` Alexander Duyck
2015-11-25 17:24 ` Alexander Duyck
2015-11-25 17:24 ` [Qemu-devel] " Alexander Duyck
2015-11-24 14:20 ` [RFC PATCH V2 0/3] IXGBE/VFIO: Add live migration support for SRIOV NIC Alexander Duyck
2015-11-24 14:20 ` [Intel-wired-lan] " Alexander Duyck
2015-11-24 14:20 ` [Qemu-devel] " Alexander Duyck
2015-11-25 3:18 ` Lan Tianyu
2015-11-25 3:18 ` [Intel-wired-lan] " Lan Tianyu
2015-11-25 3:18 ` Lan Tianyu
2015-11-25 3:18 ` [Qemu-devel] " Lan Tianyu
2015-11-25 5:30 ` Alexander Duyck
2015-11-25 5:30 ` [Intel-wired-lan] " Alexander Duyck
2015-11-25 5:30 ` Alexander Duyck
2015-11-25 5:30 ` Alexander Duyck
2015-11-25 5:30 ` [Qemu-devel] " Alexander Duyck
2015-11-25 8:21 ` Lan Tianyu
2015-11-25 8:21 ` [Intel-wired-lan] " Lan Tianyu
2015-11-25 8:21 ` Lan Tianyu
2015-11-25 8:21 ` Lan Tianyu
2015-11-25 8:21 ` [Qemu-devel] " Lan Tianyu
2015-11-25 15:32 ` Alexander Duyck
2015-11-25 15:32 ` [Intel-wired-lan] " Alexander Duyck
2015-11-25 15:32 ` Alexander Duyck
2015-11-25 15:32 ` Alexander Duyck
2015-11-25 15:32 ` [Qemu-devel] " Alexander Duyck
2015-11-26 3:15 ` Dong, Eddie
2015-11-26 3:15 ` [Intel-wired-lan] " Dong, Eddie
2015-11-26 3:15 ` Dong, Eddie
2015-11-26 3:15 ` Dong, Eddie
2015-11-26 3:15 ` [Qemu-devel] " Dong, Eddie
2015-11-26 3:56 ` Alexander Duyck
2015-11-26 3:56 ` [Intel-wired-lan] " Alexander Duyck
2015-11-26 3:56 ` Alexander Duyck
2015-11-26 3:56 ` Alexander Duyck
2015-11-26 3:56 ` [Qemu-devel] " Alexander Duyck
2015-11-30 6:53 ` Lan, Tianyu
2015-11-30 6:53 ` [Intel-wired-lan] " Lan, Tianyu
2015-11-30 6:53 ` Lan, Tianyu
2015-11-30 6:53 ` Lan, Tianyu
2015-11-30 6:53 ` [Qemu-devel] " Lan, Tianyu
2015-11-30 16:07 ` Alexander Duyck
2015-11-30 16:07 ` [Intel-wired-lan] " Alexander Duyck
2015-11-30 16:07 ` Alexander Duyck
2015-11-30 16:07 ` [Qemu-devel] " Alexander Duyck
2015-12-01 15:04 ` Lan, Tianyu
2015-12-01 15:04 ` [Intel-wired-lan] " Lan, Tianyu
2015-12-01 15:04 ` Lan, Tianyu
2015-12-01 15:04 ` [Qemu-devel] " Lan, Tianyu
2015-12-01 15:28 ` Michael S. Tsirkin
2015-12-01 15:28 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-12-01 15:28 ` Michael S. Tsirkin
2015-12-01 15:28 ` Michael S. Tsirkin
2015-12-01 15:28 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-01 17:04 ` Alexander Duyck
2015-12-01 17:04 ` [Intel-wired-lan] " Alexander Duyck
2015-12-01 17:04 ` Alexander Duyck
2015-12-01 17:04 ` [Qemu-devel] " Alexander Duyck
2015-12-01 17:37 ` Michael S. Tsirkin
2015-12-01 17:37 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-12-01 17:37 ` Michael S. Tsirkin
2015-12-01 17:37 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-01 18:36 ` Alexander Duyck
2015-12-01 18:36 ` [Intel-wired-lan] " Alexander Duyck
2015-12-01 18:36 ` Alexander Duyck
2015-12-01 18:36 ` [Qemu-devel] " Alexander Duyck
2015-12-02 11:44 ` Michael S. Tsirkin
2015-12-02 11:44 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-12-02 11:44 ` Michael S. Tsirkin
2015-12-02 11:44 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-04 16:32 ` Lan, Tianyu
2015-12-04 16:32 ` [Intel-wired-lan] " Lan, Tianyu
2015-12-04 16:32 ` Lan, Tianyu
2015-12-04 16:32 ` Lan, Tianyu
2015-12-04 16:32 ` [Qemu-devel] " Lan, Tianyu
2015-12-04 17:07 ` Alexander Duyck
2015-12-04 17:07 ` [Intel-wired-lan] " Alexander Duyck
2015-12-04 17:07 ` Alexander Duyck
2015-12-04 17:07 ` Alexander Duyck
2015-12-04 17:07 ` [Qemu-devel] " Alexander Duyck
2015-12-07 15:40 ` Lan, Tianyu
2015-12-07 15:40 ` [Intel-wired-lan] " Lan, Tianyu
2015-12-07 15:40 ` Lan, Tianyu
2015-12-07 15:40 ` Lan, Tianyu
2015-12-07 15:40 ` [Qemu-devel] " Lan, Tianyu
2015-12-07 17:12 ` Alexander Duyck
2015-12-07 17:12 ` [Intel-wired-lan] " Alexander Duyck
2015-12-07 17:12 ` Alexander Duyck
2015-12-07 17:12 ` [Qemu-devel] " Alexander Duyck
2015-12-07 17:39 ` Michael S. Tsirkin
2015-12-07 17:39 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-12-07 17:39 ` Michael S. Tsirkin
2015-12-07 17:39 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-07 18:42 ` Alexander Duyck
2015-12-07 18:42 ` [Intel-wired-lan] " Alexander Duyck
2015-12-07 18:42 ` Alexander Duyck
2015-12-07 18:42 ` [Qemu-devel] " Alexander Duyck
2015-12-09 9:28 ` Lan, Tianyu
2015-12-09 9:28 ` [Intel-wired-lan] " Lan, Tianyu
2015-12-09 9:28 ` Lan, Tianyu
2015-12-09 9:28 ` [Qemu-devel] " Lan, Tianyu
2015-12-09 16:36 ` Alexander Duyck
2015-12-09 16:36 ` [Intel-wired-lan] " Alexander Duyck
2015-12-09 16:36 ` Alexander Duyck
2015-12-09 16:36 ` [Qemu-devel] " Alexander Duyck
2015-12-09 10:37 ` Michael S. Tsirkin
2015-12-09 10:37 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-12-09 10:37 ` Michael S. Tsirkin
2015-12-09 10:37 ` Michael S. Tsirkin
2015-12-09 10:37 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-09 11:19 ` Lan, Tianyu [this message]
2015-12-09 11:19 ` [Intel-wired-lan] " Lan, Tianyu
2015-12-09 11:19 ` Lan, Tianyu
2015-12-09 11:19 ` Lan, Tianyu
2015-12-09 11:19 ` [Qemu-devel] " Lan, Tianyu
2015-12-09 11:28 ` Michael S. Tsirkin
2015-12-09 11:28 ` [Intel-wired-lan] " Michael S. Tsirkin
2015-12-09 11:28 ` Michael S. Tsirkin
2015-12-09 11:28 ` Michael S. Tsirkin
2015-12-09 11:28 ` [Qemu-devel] " Michael S. Tsirkin
2015-12-09 11:41 ` Lan, Tianyu
2015-12-09 11:41 ` [Intel-wired-lan] " Lan, Tianyu
2015-12-09 11:41 ` Lan, Tianyu
2015-12-09 11:41 ` Lan, Tianyu
2015-12-09 11:41 ` [Qemu-devel] " Lan, Tianyu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56680E33.6040204@intel.com \
--to=tianyu.lan@intel.com \
--cc=a.motakis@virtualopensystems.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=b.reynal@virtualopensystems.com \
--cc=bhelgaas@google.com \
--cc=carolyn.wyborny@intel.com \
--cc=donald.c.skidmore@intel.com \
--cc=eddie.dong@intel.com \
--cc=emil.s.tantilov@intel.com \
--cc=eric.auger@linaro.org \
--cc=gerlitz.or@gmail.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=john.ronciak@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.d.rustad@intel.com \
--cc=mitch.a.williams@intel.com \
--cc=mst@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nrupal.jani@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shannon.nelson@intel.com \
--cc=weiyang@linux.vnet.ibm.com \
--cc=zajec5@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.