search for: vugenfirer

On Thu, Oct 29, 2015 at 10:33:57AM +0200, Yan Vugenfirer wrote: > > On 29 Oct 2015, at 10:28, Richard W.M. Jones <rjones@redhat.com> wrote: > > On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > > > > Seems like looking at this field in the .inf file is better than our > > current approach of matching...

...ozenfeld" <vrozenfe@redhat.com>, "Li Jin" <lijin@redhat.com> > Cc: "Richard W.M. Jones" <rjones@redhat.com>, "Roman Kagan" <rkagan@virtuozzo.com>, libguestfs@redhat.com, "Jeff > Nelson" <jenelson@redhat.com>, "Yan Vugenfirer" <yvugenfi@redhat.com>, "Denis Lunev" <den@virtuozzo.com> > Sent: Wednesday, November 18, 2015 6:29:11 PM > Subject: Re: [PATCH] v2v: virtio-win: include *.dll too > > > +Li Jin > > ----- Original Message ----- > > From: "Vadim Rozenfeld...

...t; <vrozenfe@redhat.com> > To: "Richard W.M. Jones" <rjones@redhat.com> > Cc: "Roman Kagan" <rkagan@virtuozzo.com>, libguestfs@redhat.com, "Amnon Ilan" <ailan@redhat.com>, "Jeff Nelson" > <jenelson@redhat.com>, "Yan Vugenfirer" <yvugenfi@redhat.com>, "Denis Lunev" <den@virtuozzo.com> > Sent: Wednesday, November 18, 2015 6:00:12 AM > Subject: Re: Fwd: [PATCH] v2v: virtio-win: include *.dll too > > On Tue, 2015-11-17 at 19:44 +0000, Richard W.M. Jones wrote: > > I think one - m...

On Wed, Oct 28, 2015 at 12:10:19PM +1100, Vadim Rozenfeld wrote: > > > > To sum up, the packaging and naming policy of the virtio-win rpm and the > > > > virtio-win iso therein are different and neither is clear. Hardcoding > > > > the policy in v2v without actually knowing it appears risky at best. > > It's due to historical reasons mostly. The best

Document VIRTIO_NET_CTRL_GUEST_OFFLOADS and the relevant feature bits. Will allow ethtool control of the offloads down the road. Reported-by: Yan Vugenfirer <yan at daynix.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/uapi/linux/virtio_net.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h index 7bbee79..ec32293 100644 --- a/incl...

On Wed, Oct 28, 2015 at 04:15:06PM +0200, Yan Vugenfirer wrote: > Otherwise you will have to maintain the knowledge of binary > compatibility between Windows platforms, which is different > according to the driver type. What does this mean? Could you give an example? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat...

Thanks: Yan Vugenfirer. --- v2v/virt-v2v.pod | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index c6810aab7..f9f659cef 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1139,6 +1139,20 @@ This can also prevent booting with a 7B error [see previous section]...

Document VIRTIO_NET_CTRL_GUEST_OFFLOADS and the relevant feature bits. Will allow ethtool control of the offloads down the road. Reported-by: Yan Vugenfirer <yan at daynix.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- include/uapi/linux/virtio_net.h | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h index 7bbee79..ec32293 100644 --- a/incl...

On Mon, 2015-11-09 at 18:08 +0300, Roman Kagan wrote: > On Sun, Nov 08, 2015 at 10:15:31AM +0200, Yan Vugenfirer wrote: > > > > > On 06 Nov 2015, at 08:51, Vadim Rozenfeld <vrozenfe@redhat.com> wrote: > > > > > > On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote: > > >> On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > > &gt...

On Sun, Nov 08, 2015 at 10:15:31AM +0200, Yan Vugenfirer wrote: > > > On 06 Nov 2015, at 08:51, Vadim Rozenfeld <vrozenfe@redhat.com> wrote: > > > > On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote: > >> On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > >>> On Wed, 2015-10-28 a...

> On 06 Nov 2015, at 08:51, Vadim Rozenfeld <vrozenfe@redhat.com> wrote: > > On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote: >> On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: >>> On Wed, 2015-10-28 at 14:53 +0300, Roman Kagan wrote: >>>> 1) tell which devices can be configured >>> Not sure that I fully understated

On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > > 1) tell which devices can be configured > Not sure that I fully understated your question. but if you are going to > create some sort of off-line automatic virtio-win drivers update > utility, then it shouldn't be too complicated. Roman is talking about what virt-v2v already does. This is good information:

Hi, I am the guy who puts together the virtio-win package for Red Hat. I recently took over this role so I'm still in learning mode. On Wed, Oct 28, 2015 at 04:15:06PM +0200, Yan Vugenfirer wrote: >> On 28 Oct 2015, at 13:53, Roman Kagan <rkagan@virtuozzo.com> wrote: >> On Wed, Oct 28, 2015 at 12:10:19PM +1100, Vadim Rozenfeld wrote: >>>>>> To sum up, the packaging and naming policy of the virtio-win rpm and the >>>>>> virtio-win i...

I think one - maybe final? - problem. How can I tell the difference between drivers for "client" versions of Windows (eg. Windows 7) and server versions of Windows (eg. Windows 2008 Server)? It seems in many or most cases the drivers are identical, eg: $ md5sum viostor/2k12/amd64/* viostor/w8/amd64/* bbe250c13bf891fd7292ccab9908a63a viostor/2k12/amd64/viostor.cat

...> >>> and I should be submitting patches or pull requests to it? >> >> Yes, that's what I use to package the drivers for RHEL. >> >> >>> Or should the layout be determined only by the build machinery at >>> >>> https://github.com/YanVugenfirer/kvm-guest-drivers-windows >>> >>> and I should be direct my submissions that way? >> >> I don't know, but if you work strictly with virtio-win-pkg-scripts it >> shouldn't matter. > > Thanks a lot, I'll look into it early next week. > Sorry...

...idong@huawei.com> Wen Congyang <wency@cn.fujitsu.com> Wenchao Xia <xiawenc@linux.vnet.ibm.com> Wendy Liang <jliang@xilinx.com> Will Auld <will.auld@intel.com> Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Xudong Hao <xudong.hao@intel.com> Yan Vugenfirer <yan@daynix.com> Yeongkyoon Lee <yeongkyoon.lee@samsung.com> Yin Yin <yin.yin@cs2c.com.cn> Yongbok Kim <yongbok.kim@imgtec.com> zhangleiqiang <zhangleiqiang@huawei.com> Zhenguo Wang <wangzhenguo@huawei.com> Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>...

...idong@huawei.com> Wen Congyang <wency@cn.fujitsu.com> Wenchao Xia <xiawenc@linux.vnet.ibm.com> Wendy Liang <jliang@xilinx.com> Will Auld <will.auld@intel.com> Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Xudong Hao <xudong.hao@intel.com> Yan Vugenfirer <yan@daynix.com> Yeongkyoon Lee <yeongkyoon.lee@samsung.com> Yin Yin <yin.yin@cs2c.com.cn> Yongbok Kim <yongbok.kim@imgtec.com> zhangleiqiang <zhangleiqiang@huawei.com> Zhenguo Wang <wangzhenguo@huawei.com> Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>...

...idong@huawei.com> Wen Congyang <wency@cn.fujitsu.com> Wenchao Xia <xiawenc@linux.vnet.ibm.com> Wendy Liang <jliang@xilinx.com> Will Auld <will.auld@intel.com> Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> Xudong Hao <xudong.hao@intel.com> Yan Vugenfirer <yan@daynix.com> Yeongkyoon Lee <yeongkyoon.lee@samsung.com> Yin Yin <yin.yin@cs2c.com.cn> Yongbok Kim <yongbok.kim@imgtec.com> zhangleiqiang <zhangleiqiang@huawei.com> Zhenguo Wang <wangzhenguo@huawei.com> Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>...

Hi Stefan, Michael, Jason and everyone, Several days ago, I discussed with jason about "Vsock over Virtio-net". This idea has two advantages: First, it can use many great features of virtio-net, like batching, mergeable rx buffer and multiqueue, etc. Second, it can reduce many duplicate codes and make it easy to be maintained. Before the implement, I want to discuss with everyone

Hi Stefan, Michael, Jason and everyone, Several days ago, I discussed with jason about "Vsock over Virtio-net". This idea has two advantages: First, it can use many great features of virtio-net, like batching, mergeable rx buffer and multiqueue, etc. Second, it can reduce many duplicate codes and make it easy to be maintained. Before the implement, I want to discuss with everyone