On Wed, Dec 9, 2015 at 1:28 AM, Lan, Tianyu wrote:
>
>
> On 12/8/2015 1:12 AM, Alexander Duyck wrote:
>>
>> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
>>>
>>> On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>
>
>
> We still need to support Windows guest for migration and
On 12/9/2015 7:28 PM, Michael S. Tsirkin wrote:
I remember reading that it's possible to implement a bus driver
on windows if required. But basically I don't see how windows can be
relevant to discussing guest driver patches. That discussion
probably belongs on the qemu maling list, not on
On Wed, Dec 09, 2015 at 07:19:15PM +0800, Lan, Tianyu wrote:
> 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
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:
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
>
On 12/8/2015 1:12 AM, Alexander Duyck wrote:
On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
On 12/5/2015 1:07 AM, Alexander Duyck wrote:
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
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
>
On 12/8/2015 1:12 AM, Alexander Duyck wrote:
On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
On 12/5/2015 1:07 AM, Alexander Duyck wrote:
We still need to support Windows guest for migration and this is why our
patches keep all changes in the driver since it's
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:
On 12/9/2015 7:28 PM, Michael S. Tsirkin wrote:
I remember reading that it's possible to implement a bus driver
on windows if required. But basically I don't see how windows can be
relevant to discussing guest driver patches. That discussion
probably belongs on the qemu maling list, not on
On Wed, Dec 09, 2015 at 07:19:15PM +0800, Lan, Tianyu wrote:
> 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
On Wed, Dec 9, 2015 at 1:28 AM, Lan, Tianyu wrote:
>
>
> On 12/8/2015 1:12 AM, Alexander Duyck wrote:
>>
>> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
>>>
>>> On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>
>
>
> We still need to
On Mon, Dec 7, 2015 at 9:39 AM, Michael S. Tsirkin wrote:
> On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote:
>> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
>> > On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>> > If can't do that, we have to stop DMA in a short time to mark
On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote:
> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
> > On 12/5/2015 1:07 AM, Alexander Duyck wrote:
> >>>
> >>>
> >>> We still need to support Windows guest for migration and this is why our
> >>> patches keep all changes in the
On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
> On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>>>
>>>
>>> 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.
>>
>>
>> That is a
On 12/5/2015 1:07 AM, Alexander Duyck wrote:
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.
That is a poor argument. I highly doubt Microsoft is interested in
having to modify all
On 12/5/2015 1:07 AM, Alexander Duyck wrote:
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.
That is a poor argument. I highly doubt Microsoft is interested in
having to modify all
On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
> On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>>>
>>>
>>> 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
On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote:
> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
> > On 12/5/2015 1:07 AM, Alexander Duyck wrote:
> >>>
> >>>
> >>> We still need to support Windows guest for migration and this is why our
> >>> patches
On Mon, Dec 7, 2015 at 9:39 AM, Michael S. Tsirkin wrote:
> On Mon, Dec 07, 2015 at 09:12:08AM -0800, Alexander Duyck wrote:
>> On Mon, Dec 7, 2015 at 7:40 AM, Lan, Tianyu wrote:
>> > On 12/5/2015 1:07 AM, Alexander Duyck wrote:
>> > If can't do that, we
On 12/04/2015 08:32 AM, Lan, Tianyu wrote:
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
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.
That is a poor
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
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.
Following is my idea to do DMA tracking.
Inject event to VF
On 12/04/2015 08:32 AM, Lan, Tianyu wrote:
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
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.
That is a poor
Hi Michael & Alexander:
Thanks a lot for your comments and suggestions.
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.
Following is my idea to do DMA tracking.
Inject event to VF
On Tue, Dec 01, 2015 at 10:36:33AM -0800, Alexander Duyck wrote:
> On Tue, Dec 1, 2015 at 9:37 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 01, 2015 at 09:04:32AM -0800, Alexander Duyck wrote:
> >> On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
>
> >> > There are several components
On Tue, Dec 01, 2015 at 10:36:33AM -0800, Alexander Duyck wrote:
> On Tue, Dec 1, 2015 at 9:37 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 01, 2015 at 09:04:32AM -0800, Alexander Duyck wrote:
> >> On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
>
>
On Tue, Dec 1, 2015 at 9:37 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 01, 2015 at 09:04:32AM -0800, Alexander Duyck wrote:
>> On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
>> > There are several components to this:
>> > - dma_map_* needs to prevent page from
>> > being migrated
On Tue, Dec 01, 2015 at 09:04:32AM -0800, Alexander Duyck wrote:
> On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 01, 2015 at 11:04:31PM +0800, Lan, Tianyu wrote:
> >>
> >>
> >> On 12/1/2015 12:07 AM, Alexander Duyck wrote:
> >> >They can only be corrected if the
On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 01, 2015 at 11:04:31PM +0800, Lan, Tianyu wrote:
>>
>>
>> On 12/1/2015 12:07 AM, Alexander Duyck wrote:
>> >They can only be corrected if the underlying assumptions are correct
>> >and they aren't. Your solution would have
On Tue, Dec 01, 2015 at 11:04:31PM +0800, Lan, Tianyu wrote:
>
>
> On 12/1/2015 12:07 AM, Alexander Duyck wrote:
> >They can only be corrected if the underlying assumptions are correct
> >and they aren't. Your solution would have never worked correctly.
> >The problem is you assume you can keep
On 12/1/2015 12:07 AM, Alexander Duyck wrote:
They can only be corrected if the underlying assumptions are correct
and they aren't. Your solution would have never worked correctly.
The problem is you assume you can keep the device running when you are
migrating and you simply cannot. At some
On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 01, 2015 at 11:04:31PM +0800, Lan, Tianyu wrote:
>>
>>
>> On 12/1/2015 12:07 AM, Alexander Duyck wrote:
>> >They can only be corrected if the underlying assumptions are correct
>> >and they aren't. Your
On Tue, Dec 01, 2015 at 09:04:32AM -0800, Alexander Duyck wrote:
> On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
> > On Tue, Dec 01, 2015 at 11:04:31PM +0800, Lan, Tianyu wrote:
> >>
> >>
> >> On 12/1/2015 12:07 AM, Alexander Duyck wrote:
> >> >They can only be
On Tue, Dec 1, 2015 at 9:37 AM, Michael S. Tsirkin wrote:
> On Tue, Dec 01, 2015 at 09:04:32AM -0800, Alexander Duyck wrote:
>> On Tue, Dec 1, 2015 at 7:28 AM, Michael S. Tsirkin wrote:
>> > There are several components to this:
>> > - dma_map_* needs to
On Tue, Dec 01, 2015 at 11:04:31PM +0800, Lan, Tianyu wrote:
>
>
> On 12/1/2015 12:07 AM, Alexander Duyck wrote:
> >They can only be corrected if the underlying assumptions are correct
> >and they aren't. Your solution would have never worked correctly.
> >The problem is you assume you can keep
On 12/1/2015 12:07 AM, Alexander Duyck wrote:
They can only be corrected if the underlying assumptions are correct
and they aren't. Your solution would have never worked correctly.
The problem is you assume you can keep the device running when you are
migrating and you simply cannot. At some
On Sun, Nov 29, 2015 at 10:53 PM, Lan, Tianyu wrote:
> On 11/26/2015 11:56 AM, Alexander Duyck wrote:
>>
>> > I am not saying you cannot modify the drivers, however what you are
>> doing is far too invasive. Do you seriously plan on modifying all of
>> the PCI device drivers out there in order
On Sun, Nov 29, 2015 at 10:53 PM, Lan, Tianyu wrote:
> On 11/26/2015 11:56 AM, Alexander Duyck wrote:
>>
>> > I am not saying you cannot modify the drivers, however what you are
>> doing is far too invasive. Do you seriously plan on modifying all of
>> the PCI device
On 11/26/2015 11:56 AM, Alexander Duyck wrote:
> I am not saying you cannot modify the drivers, however what you are
doing is far too invasive. Do you seriously plan on modifying all of
the PCI device drivers out there in order to allow any device that
might be direct assigned to a port to
On 11/26/2015 11:56 AM, Alexander Duyck wrote:
> I am not saying you cannot modify the drivers, however what you are
doing is far too invasive. Do you seriously plan on modifying all of
the PCI device drivers out there in order to allow any device that
might be direct assigned to a port to
On Wed, Nov 25, 2015 at 7:15 PM, Dong, Eddie wrote:
>> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote:
>> > On 2015年11月25日 13:30, Alexander Duyck wrote:
>> >> No, what I am getting at is that you can't go around and modify the
>> >> configuration space for every possible device out there.
> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote:
> > On 2015年11月25日 13:30, Alexander Duyck wrote:
> >> No, what I am getting at is that you can't go around and modify the
> >> configuration space for every possible device out there. This
> >> solution won't scale.
> >
> >
> > PCI config
On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote:
> On 2015年11月25日 13:30, Alexander Duyck wrote:
>> No, what I am getting at is that you can't go around and modify the
>> configuration space for every possible device out there. This
>> solution won't scale.
>
>
> PCI config space regs are
On 2015年11月25日 13:30, Alexander Duyck wrote:
> No, what I am getting at is that you can't go around and modify the
> configuration space for every possible device out there. This
> solution won't scale.
PCI config space regs are emulation by Qemu and so We can find the free
PCI config space
On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote:
> On 2015年11月25日 13:30, Alexander Duyck wrote:
>> No, what I am getting at is that you can't go around and modify the
>> configuration space for every possible device out there. This
>> solution won't scale.
>
>
> PCI
On Wed, Nov 25, 2015 at 7:15 PM, Dong, Eddie wrote:
>> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote:
>> > On 2015年11月25日 13:30, Alexander Duyck wrote:
>> >> No, what I am getting at is that you can't go around and modify the
>> >> configuration
> On Wed, Nov 25, 2015 at 12:21 AM, Lan Tianyu wrote:
> > On 2015年11月25日 13:30, Alexander Duyck wrote:
> >> No, what I am getting at is that you can't go around and modify the
> >> configuration space for every possible device out there. This
> >> solution won't scale.
> >
On 2015年11月25日 13:30, Alexander Duyck wrote:
> No, what I am getting at is that you can't go around and modify the
> configuration space for every possible device out there. This
> solution won't scale.
PCI config space regs are emulation by Qemu and so We can find the free
PCI config space
On Tue, Nov 24, 2015 at 7:18 PM, Lan Tianyu wrote:
> On 2015年11月24日 22:20, Alexander Duyck wrote:
>> I'm still not a fan of this approach. I really feel like this is
>> something that should be resolved by extending the existing PCI hot-plug
>> rather than trying to instrument this per driver.
On 2015年11月24日 22:20, Alexander Duyck wrote:
> I'm still not a fan of this approach. I really feel like this is
> something that should be resolved by extending the existing PCI hot-plug
> rather than trying to instrument this per driver. Then you will get the
> goodness for multiple drivers and
On 11/24/2015 05:38 AM, Lan Tianyu wrote:
This patchset is to propose a solution of adding live migration
support for SRIOV NIC.
During migration, Qemu needs to let VF driver in the VM to know
migration start and end. Qemu adds faked PCI migration capability
to help to sync status between two
On 2015年11月24日 22:20, Alexander Duyck wrote:
> I'm still not a fan of this approach. I really feel like this is
> something that should be resolved by extending the existing PCI hot-plug
> rather than trying to instrument this per driver. Then you will get the
> goodness for multiple drivers and
On Tue, Nov 24, 2015 at 7:18 PM, Lan Tianyu wrote:
> On 2015年11月24日 22:20, Alexander Duyck wrote:
>> I'm still not a fan of this approach. I really feel like this is
>> something that should be resolved by extending the existing PCI hot-plug
>> rather than trying to
On 11/24/2015 05:38 AM, Lan Tianyu wrote:
This patchset is to propose a solution of adding live migration
support for SRIOV NIC.
During migration, Qemu needs to let VF driver in the VM to know
migration start and end. Qemu adds faked PCI migration capability
to help to sync status between two
54 matches
Mail list logo