From: Alexander Duyck <alexander.duyck@gmail.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Lan Tianyu <tianyu.lan@intel.com>,
a.motakis@virtualopensystems.com,
Alex Williamson <alex.williamson@redhat.com>,
b.reynal@virtualopensystems.com,
Bjorn Helgaas <bhelgaas@google.com>,
Carolyn Wyborny <carolyn.wyborny@intel.com>,
"Skidmore, Donald C" <donald.c.skidmore@intel.com>,
eddie.dong@intel.com, nrupal.jani@intel.com,
Alexander Graf <agraf@suse.de>,
kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
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>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
"Brandeburg, Jesse" <jesse.brandeburg@intel.com>,
"Ronciak, John" <john.ronciak@intel.com>,
linux-api@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mitch Williams <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
Subject: Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver
Date: Tue, 24 Nov 2015 21:39:23 -0800 [thread overview]
Message-ID: <CAKgT0UcTHPfX7wh_niV=nP14hU5N44sRuKmVrMcSSc_DqYPXrA@mail.gmail.com> (raw)
In-Reply-To: <20151124230551-mutt-send-email-mst@redhat.com>
On Tue, Nov 24, 2015 at 1:20 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Nov 24, 2015 at 09:38:18PM +0800, Lan Tianyu wrote:
>> This patch is to add migration support for ixgbevf driver. Using
>> faked PCI migration capability table communicates with Qemu to
>> share migration status and mailbox irq vector index.
>>
>> Qemu will notify VF via sending MSIX msg to trigger mailbox
>> vector during migration and store migration status in the
>> PCI_VF_MIGRATION_VMM_STATUS regs in the new capability table.
>> The mailbox irq will be triggered just befoe stop-and-copy stage
>> and after migration on the target machine.
>>
>> VF driver will put down net when detect migration and tell
>> Qemu it's ready for migration via writing PCI_VF_MIGRATION_VF_STATUS
>> reg. After migration, put up net again.
>>
>> Qemu will in charge of migrating PCI config space regs and MSIX config.
>>
>> The patch is to dedicate on the normal case that net traffic works
>> when mailbox irq is enabled. For other cases(such as the driver
>> isn't loaded, adapter is suspended or closed), mailbox irq won't be
>> triggered and VF driver will disable it via PCI_VF_MIGRATION_CAP
>> reg. These case will be resolved later.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>
> I have to say, I was much more interested in the idea
> of tracking dirty memory. I have some thoughts about
> that one - did you give up on it then?
The tracking of dirty pages still needs to be addressed unless the
interface is being downed before migration even starts which based on
other comments I am assuming is not the case.
I still feel that having a means of marking a page as being dirty when
it is unmapped would be the best way to go. That way you only have to
update the DMA API instead of messing with each and every driver
trying to add code to force the page to be dirtied.
- Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.duyck@gmail.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, qemu-devel@nongnu.org, "Brandeburg,
Jesse" <jesse.brandeburg@intel.com>,
"Rustad, Mark D" <mark.d.rustad@intel.com>,
Carolyn Wyborny <carolyn.wyborny@intel.com>,
Eric Auger <eric.auger@linaro.org>,
"Skidmore, Donald C" <donald.c.skidmore@intel.com>,
zajec5@gmail.com, Alexander Graf <agraf@suse.de>,
intel-wired-lan <intel-wired-lan@lists.osuosl.org>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Or Gerlitz <gerlitz.or@gmail.com>,
Mitch Williams <mitch.a.williams@intel.com>,
nrupal.jani@intel.com, Bjorn Helgaas <bhelgaas@google.com>,
a.motakis@virtualopensystems.com,
Lan Tianyu <tianyu.lan@intel.com>,
b.reynal@virtualopensystems.com, linux-api@vger.kernel.org,
"Nelson, Shannon" <shannon.nelson@intel.com>,
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 3/3] Ixgbevf: Add migration support for ixgbevf driver
Date: Tue, 24 Nov 2015 21:39:23 -0800 [thread overview]
Message-ID: <CAKgT0UcTHPfX7wh_niV=nP14hU5N44sRuKmVrMcSSc_DqYPXrA@mail.gmail.com> (raw)
In-Reply-To: <20151124230551-mutt-send-email-mst@redhat.com>
On Tue, Nov 24, 2015 at 1:20 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Nov 24, 2015 at 09:38:18PM +0800, Lan Tianyu wrote:
>> This patch is to add migration support for ixgbevf driver. Using
>> faked PCI migration capability table communicates with Qemu to
>> share migration status and mailbox irq vector index.
>>
>> Qemu will notify VF via sending MSIX msg to trigger mailbox
>> vector during migration and store migration status in the
>> PCI_VF_MIGRATION_VMM_STATUS regs in the new capability table.
>> The mailbox irq will be triggered just befoe stop-and-copy stage
>> and after migration on the target machine.
>>
>> VF driver will put down net when detect migration and tell
>> Qemu it's ready for migration via writing PCI_VF_MIGRATION_VF_STATUS
>> reg. After migration, put up net again.
>>
>> Qemu will in charge of migrating PCI config space regs and MSIX config.
>>
>> The patch is to dedicate on the normal case that net traffic works
>> when mailbox irq is enabled. For other cases(such as the driver
>> isn't loaded, adapter is suspended or closed), mailbox irq won't be
>> triggered and VF driver will disable it via PCI_VF_MIGRATION_CAP
>> reg. These case will be resolved later.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>
> I have to say, I was much more interested in the idea
> of tracking dirty memory. I have some thoughts about
> that one - did you give up on it then?
The tracking of dirty pages still needs to be addressed unless the
interface is being downed before migration even starts which based on
other comments I am assuming is not the case.
I still feel that having a means of marking a page as being dirty when
it is unmapped would be the best way to go. That way you only have to
update the DMA API instead of messing with each and every driver
trying to add code to force the page to be dirtied.
- Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.duyck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Lan Tianyu <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@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,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Carolyn Wyborny
<carolyn.wyborny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Skidmore,
Donald C"
<donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
nrupal.jani-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@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>,
Jeff Kirsher
<jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Brandeburg,
Jesse" <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Ronciak,
John" <john.ronciak-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TaqPxH82wqD4g@public.gmane.org
Subject: Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver
Date: Tue, 24 Nov 2015 21:39:23 -0800 [thread overview]
Message-ID: <CAKgT0UcTHPfX7wh_niV=nP14hU5N44sRuKmVrMcSSc_DqYPXrA@mail.gmail.com> (raw)
In-Reply-To: <20151124230551-mutt-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Nov 24, 2015 at 1:20 PM, Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Nov 24, 2015 at 09:38:18PM +0800, Lan Tianyu wrote:
>> This patch is to add migration support for ixgbevf driver. Using
>> faked PCI migration capability table communicates with Qemu to
>> share migration status and mailbox irq vector index.
>>
>> Qemu will notify VF via sending MSIX msg to trigger mailbox
>> vector during migration and store migration status in the
>> PCI_VF_MIGRATION_VMM_STATUS regs in the new capability table.
>> The mailbox irq will be triggered just befoe stop-and-copy stage
>> and after migration on the target machine.
>>
>> VF driver will put down net when detect migration and tell
>> Qemu it's ready for migration via writing PCI_VF_MIGRATION_VF_STATUS
>> reg. After migration, put up net again.
>>
>> Qemu will in charge of migrating PCI config space regs and MSIX config.
>>
>> The patch is to dedicate on the normal case that net traffic works
>> when mailbox irq is enabled. For other cases(such as the driver
>> isn't loaded, adapter is suspended or closed), mailbox irq won't be
>> triggered and VF driver will disable it via PCI_VF_MIGRATION_CAP
>> reg. These case will be resolved later.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> I have to say, I was much more interested in the idea
> of tracking dirty memory. I have some thoughts about
> that one - did you give up on it then?
The tracking of dirty pages still needs to be addressed unless the
interface is being downed before migration even starts which based on
other comments I am assuming is not the case.
I still feel that having a means of marking a page as being dirty when
it is unmapped would be the best way to go. That way you only have to
update the DMA API instead of messing with each and every driver
trying to add code to force the page to be dirtied.
- Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.duyck-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Lan Tianyu <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@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,
Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Carolyn Wyborny
<carolyn.wyborny-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Skidmore,
Donald C"
<donald.c.skidmore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
eddie.dong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
nrupal.jani-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>,
kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Paolo Bonzini <pbonzini-H+wXaHxf7aLQT0dZR+AlfA@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>,
Jeff Kirsher
<jeffrey.t.kirsher-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Brandeburg,
Jesse" <jesse.brandeburg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
"Ronciak,
John" <john.ronciak-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TaqPxH82wqD4g@public.gmane.org>
Subject: Re: [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver
Date: Tue, 24 Nov 2015 21:39:23 -0800 [thread overview]
Message-ID: <CAKgT0UcTHPfX7wh_niV=nP14hU5N44sRuKmVrMcSSc_DqYPXrA@mail.gmail.com> (raw)
In-Reply-To: <20151124230551-mutt-send-email-mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Nov 24, 2015 at 1:20 PM, Michael S. Tsirkin <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> On Tue, Nov 24, 2015 at 09:38:18PM +0800, Lan Tianyu wrote:
>> This patch is to add migration support for ixgbevf driver. Using
>> faked PCI migration capability table communicates with Qemu to
>> share migration status and mailbox irq vector index.
>>
>> Qemu will notify VF via sending MSIX msg to trigger mailbox
>> vector during migration and store migration status in the
>> PCI_VF_MIGRATION_VMM_STATUS regs in the new capability table.
>> The mailbox irq will be triggered just befoe stop-and-copy stage
>> and after migration on the target machine.
>>
>> VF driver will put down net when detect migration and tell
>> Qemu it's ready for migration via writing PCI_VF_MIGRATION_VF_STATUS
>> reg. After migration, put up net again.
>>
>> Qemu will in charge of migrating PCI config space regs and MSIX config.
>>
>> The patch is to dedicate on the normal case that net traffic works
>> when mailbox irq is enabled. For other cases(such as the driver
>> isn't loaded, adapter is suspended or closed), mailbox irq won't be
>> triggered and VF driver will disable it via PCI_VF_MIGRATION_CAP
>> reg. These case will be resolved later.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> I have to say, I was much more interested in the idea
> of tracking dirty memory. I have some thoughts about
> that one - did you give up on it then?
The tracking of dirty pages still needs to be addressed unless the
interface is being downed before migration even starts which based on
other comments I am assuming is not the case.
I still feel that having a means of marking a page as being dirty when
it is unmapped would be the best way to go. That way you only have to
update the DMA API instead of messing with each and every driver
trying to add code to force the page to be dirtied.
- Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.duyck@gmail.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [RFC PATCH V2 3/3] Ixgbevf: Add migration support for ixgbevf driver
Date: Tue, 24 Nov 2015 21:39:23 -0800 [thread overview]
Message-ID: <CAKgT0UcTHPfX7wh_niV=nP14hU5N44sRuKmVrMcSSc_DqYPXrA@mail.gmail.com> (raw)
In-Reply-To: <20151124230551-mutt-send-email-mst@redhat.com>
On Tue, Nov 24, 2015 at 1:20 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Nov 24, 2015 at 09:38:18PM +0800, Lan Tianyu wrote:
>> This patch is to add migration support for ixgbevf driver. Using
>> faked PCI migration capability table communicates with Qemu to
>> share migration status and mailbox irq vector index.
>>
>> Qemu will notify VF via sending MSIX msg to trigger mailbox
>> vector during migration and store migration status in the
>> PCI_VF_MIGRATION_VMM_STATUS regs in the new capability table.
>> The mailbox irq will be triggered just befoe stop-and-copy stage
>> and after migration on the target machine.
>>
>> VF driver will put down net when detect migration and tell
>> Qemu it's ready for migration via writing PCI_VF_MIGRATION_VF_STATUS
>> reg. After migration, put up net again.
>>
>> Qemu will in charge of migrating PCI config space regs and MSIX config.
>>
>> The patch is to dedicate on the normal case that net traffic works
>> when mailbox irq is enabled. For other cases(such as the driver
>> isn't loaded, adapter is suspended or closed), mailbox irq won't be
>> triggered and VF driver will disable it via PCI_VF_MIGRATION_CAP
>> reg. These case will be resolved later.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>
> I have to say, I was much more interested in the idea
> of tracking dirty memory. I have some thoughts about
> that one - did you give up on it then?
The tracking of dirty pages still needs to be addressed unless the
interface is being downed before migration even starts which based on
other comments I am assuming is not the case.
I still feel that having a means of marking a page as being dirty when
it is unmapped would be the best way to go. That way you only have to
update the DMA API instead of messing with each and every driver
trying to add code to force the page to be dirtied.
- Alex
next prev parent reply other threads:[~2015-11-25 5:39 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 [this message]
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
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='CAKgT0UcTHPfX7wh_niV=nP14hU5N44sRuKmVrMcSSc_DqYPXrA@mail.gmail.com' \
--to=alexander.duyck@gmail.com \
--cc=a.motakis@virtualopensystems.com \
--cc=agraf@suse.de \
--cc=alex.williamson@redhat.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=tianyu.lan@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.