On 10/01/2009 09:24 PM, Gregory Haskins wrote:
>
>> Virtualization is about not doing that. Sometimes it's necessary (when
>> you have made unfixable design mistakes), but just to replace a bus,
>> with no advantages to the guest that has to be changed (other
>> hypervisors or hypervisorless deplo
Avi Kivity wrote:
> On 09/30/2009 10:04 PM, Gregory Haskins wrote:
>
>
>>> A 2.6.27 guest, or Windows guest with the existing virtio drivers,
>>> won't work
>>> over vbus.
>>>
>> Binary compatibility with existing virtio drivers, while nice to have,
>> is not a specific requirement nor goal
On Thu, Oct 01, 2009 at 10:34:17AM +0200, Avi Kivity wrote:
>> Second, I do not use ioeventfd anymore because it has too many problems
>> with the surrounding technology. However, that is a topic for a
>> different thread.
>>
>
> Please post your issues. I see ioeventfd/irqfd as critical kvm
On 09/30/2009 10:04 PM, Gregory Haskins wrote:
>> A 2.6.27 guest, or Windows guest with the existing virtio drivers, won't work
>> over vbus.
>>
> Binary compatibility with existing virtio drivers, while nice to have,
> is not a specific requirement nor goal. We will simply load an updated
Avi Kivity wrote:
> On 09/26/2009 12:32 AM, Gregory Haskins wrote:
I realize in retrospect that my choice of words above implies vbus _is_
complete, but this is not what I was saying. What I was trying to
convey is that vbus is _more_ complete. Yes, in either case some kind
>>
On 09/26/2009 12:32 AM, Gregory Haskins wrote:
>>>
>>> I realize in retrospect that my choice of words above implies vbus _is_
>>> complete, but this is not what I was saying. What I was trying to
>>> convey is that vbus is _more_ complete. Yes, in either case some kind
>>> of glue needs to be wr
On Fri, Sep 25, 2009 at 10:01:58AM -0700, Ira W. Snyder wrote:
> > + case VHOST_SET_VRING_KICK:
> > + r = copy_from_user(&f, argp, sizeof f);
> > + if (r < 0)
> > + break;
> > + eventfp = f.fd == -1 ? NULL : eventfd_fget(f.fd);
> > + if (I
Avi Kivity wrote:
> On 09/24/2009 09:03 PM, Gregory Haskins wrote:
>>
>>> I don't really see how vhost and vbus are different here. vhost expects
>>> signalling to happen through a couple of eventfds and requires someone
>>> to supply them and implement kernel support (if needed). vbus requires
>
On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> What it is: vhost net is a character device that can be used to reduce
> the number of system calls involved in virtio networking.
> Existing virtio net code is used in the guest without modification.
>
> There's similarity with
On 09/24/2009 09:03 PM, Gregory Haskins wrote:
>
>> I don't really see how vhost and vbus are different here. vhost expects
>> signalling to happen through a couple of eventfds and requires someone
>> to supply them and implement kernel support (if needed). vbus requires
>> someone to write a con
On 09/24/2009 10:27 PM, Ira W. Snyder wrote:
>>> Ira can make ira-bus, and ira-eventfd, etc, etc.
>>>
>>> Each iteration will invariably introduce duplicated parts of the stack.
>>>
>>>
>> Invariably? Use libraries (virtio-shmem.ko, libvhost.so).
>>
>>
> Referencing libraries that do
On Thu, Sep 24, 2009 at 10:18:28AM +0300, Avi Kivity wrote:
> On 09/24/2009 12:15 AM, Gregory Haskins wrote:
> >
> >>> There are various aspects about designing high-performance virtual
> >>> devices such as providing the shortest paths possible between the
> >>> physical resources and the consumer
Avi Kivity wrote:
> On 09/23/2009 10:37 PM, Avi Kivity wrote:
>>
>> Example: feature negotiation. If it happens in userspace, it's easy
>> to limit what features we expose to the guest. If it happens in the
>> kernel, we need to add an interface to let the kernel know which
>> features it should
Avi Kivity wrote:
> On 09/24/2009 12:15 AM, Gregory Haskins wrote:
>>
There are various aspects about designing high-performance virtual
devices such as providing the shortest paths possible between the
physical resources and the consumers. Conversely, we also need to
ensure th
On 09/23/2009 10:37 PM, Avi Kivity wrote:
>
> Example: feature negotiation. If it happens in userspace, it's easy
> to limit what features we expose to the guest. If it happens in the
> kernel, we need to add an interface to let the kernel know which
> features it should expose to the guest.
On 09/24/2009 12:15 AM, Gregory Haskins wrote:
>
>>> There are various aspects about designing high-performance virtual
>>> devices such as providing the shortest paths possible between the
>>> physical resources and the consumers. Conversely, we also need to
>>> ensure that we meet proper isolati
Avi Kivity wrote:
> On 09/23/2009 08:58 PM, Gregory Haskins wrote:
>>>
It also pulls parts of the device model into the host kernel.
>>> That is the point. Most of it needs to be there for performance.
>>>
>> To clarify this point:
>>
>> There are various aspects about desi
On 09/23/2009 08:58 PM, Gregory Haskins wrote:
>>
>>> It also pulls parts of the device model into the host kernel.
>>>
>> That is the point. Most of it needs to be there for performance.
>>
> To clarify this point:
>
> There are various aspects about designing high-performance virtu
Gregory Haskins wrote:
> Avi Kivity wrote:
>> On 09/23/2009 05:26 PM, Gregory Haskins wrote:
>>>
> Yes, I'm having to create my own bus model, a-la lguest, virtio-pci,
> and
> virtio-s390. It isn't especially easy. I can steal lots of code from
> the
> lguest bus model, but s
Avi Kivity wrote:
> On 09/23/2009 05:26 PM, Gregory Haskins wrote:
>>
>>
Yes, I'm having to create my own bus model, a-la lguest, virtio-pci,
and
virtio-s390. It isn't especially easy. I can steal lots of code from
the
lguest bus model, but sometimes it is good to genera
On 09/23/2009 05:26 PM, Gregory Haskins wrote:
>
>
>>> Yes, I'm having to create my own bus model, a-la lguest, virtio-pci, and
>>> virtio-s390. It isn't especially easy. I can steal lots of code from the
>>> lguest bus model, but sometimes it is good to generalize, especially
>>> after the fou
Avi Kivity wrote:
> On 09/22/2009 12:43 AM, Ira W. Snyder wrote:
>>
>>> Sure, virtio-ira and he is on his own to make a bus-model under that, or
>>> virtio-vbus + vbus-ira-connector to use the vbus framework. Either
>>> model can work, I agree.
>>>
>>>
>> Yes, I'm having to create my own bus
On 09/22/2009 06:25 PM, Ira W. Snyder wrote:
>
>> Yes. vbus is more finely layered so there is less code duplication.
>>
>> The virtio layering was more or less dictated by Xen which doesn't have
>> shared memory (it uses grant references instead). As a matter of fact
>> lguest, kvm/pci, and kvm/
On Tue, Sep 22, 2009 at 12:43:36PM +0300, Avi Kivity wrote:
> On 09/22/2009 12:43 AM, Ira W. Snyder wrote:
> >
> >> Sure, virtio-ira and he is on his own to make a bus-model under that, or
> >> virtio-vbus + vbus-ira-connector to use the vbus framework. Either
> >> model can work, I agree.
> >>
>
On 09/22/2009 12:43 AM, Ira W. Snyder wrote:
>
>> Sure, virtio-ira and he is on his own to make a bus-model under that, or
>> virtio-vbus + vbus-ira-connector to use the vbus framework. Either
>> model can work, I agree.
>>
>>
> Yes, I'm having to create my own bus model, a-la lguest, virtio
On Wed, Sep 16, 2009 at 11:11:57PM -0400, Gregory Haskins wrote:
> Avi Kivity wrote:
> > On 09/16/2009 10:22 PM, Gregory Haskins wrote:
> >> Avi Kivity wrote:
> >>
> >>> On 09/16/2009 05:10 PM, Gregory Haskins wrote:
> >>>
> > If kvm can do it, others can.
> >
> >
> >>
On Wed, Sep 16, 2009 at 10:11 PM, Gregory Haskins
wrote:
> It is certainly not a requirement to make said
> chip somehow work with existing drivers/facilities on bare metal, per
> se. Why should virtual systems be different?
i'd guess it's an issue of support resources. a hardware developer
cre
On 09/17/2009 06:11 AM, Gregory Haskins wrote:
>
>> irqfd/eventfd is the abstraction layer, it doesn't need to be reabstracted.
>>
> Not per se, but it needs to be interfaced. How do I register that
> eventfd with the fastpath in Ira's rig? How do I signal the eventfd
> (x86->ppc, and ppc->x
Michael S. Tsirkin wrote:
> On Wed, Sep 16, 2009 at 10:10:55AM -0400, Gregory Haskins wrote:
>>> There is no role reversal.
>> So if I have virtio-blk driver running on the x86 and vhost-blk device
>> running on the ppc board, I can use the ppc board as a block-device.
>> What if I really wanted to
On Wed, Sep 16, 2009 at 10:10:55AM -0400, Gregory Haskins wrote:
> > There is no role reversal.
>
> So if I have virtio-blk driver running on the x86 and vhost-blk device
> running on the ppc board, I can use the ppc board as a block-device.
> What if I really wanted to go the other way?
It seems
Avi Kivity wrote:
> On 09/16/2009 10:22 PM, Gregory Haskins wrote:
>> Avi Kivity wrote:
>>
>>> On 09/16/2009 05:10 PM, Gregory Haskins wrote:
>>>
> If kvm can do it, others can.
>
>
The problem is that you seem to either hand-wave over details like
this,
On 09/16/2009 10:22 PM, Gregory Haskins wrote:
> Avi Kivity wrote:
>
>> On 09/16/2009 05:10 PM, Gregory Haskins wrote:
>>
If kvm can do it, others can.
>>> The problem is that you seem to either hand-wave over details like this,
>>> or you give details that are pr
Avi Kivity wrote:
> On 09/16/2009 05:10 PM, Gregory Haskins wrote:
>>
>>> If kvm can do it, others can.
>>>
>> The problem is that you seem to either hand-wave over details like this,
>> or you give details that are pretty much exactly what vbus does already.
>> My point is that I've alread
On Wed, Sep 16, 2009 at 05:22:37PM +0200, Arnd Bergmann wrote:
> On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > On Wed, Sep 16, 2009 at 04:57:42PM +0200, Arnd Bergmann wrote:
> > > On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
> > > > Userspace in x86 maps a PCI region, use
On 09/16/2009 05:10 PM, Gregory Haskins wrote:
>
>> If kvm can do it, others can.
>>
> The problem is that you seem to either hand-wave over details like this,
> or you give details that are pretty much exactly what vbus does already.
> My point is that I've already sat down and thought abo
On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> On Wed, Sep 16, 2009 at 04:57:42PM +0200, Arnd Bergmann wrote:
> > On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
> > > Userspace in x86 maps a PCI region, uses it for communication with ppc?
> >
> > This might have portability i
On Wed, Sep 16, 2009 at 04:57:42PM +0200, Arnd Bergmann wrote:
> On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
> > Userspace in x86 maps a PCI region, uses it for communication with ppc?
>
> This might have portability issues. On x86 it should work, but if the
> host is powerpc or simila
On Tuesday 15 September 2009, Michael S. Tsirkin wrote:
> Userspace in x86 maps a PCI region, uses it for communication with ppc?
This might have portability issues. On x86 it should work, but if the
host is powerpc or similar, you cannot reliably access PCI I/O memory
through copy_tofrom_user but
Avi Kivity wrote:
> On 09/16/2009 02:44 PM, Gregory Haskins wrote:
>> The problem isn't where to find the models...the problem is how to
>> aggregate multiple models to the guest.
>>
>
> You mean configuration?
>
>>> You instantiate multiple vhost-nets. Multiple ethernet NICs is a
>>> suppor
On 09/16/2009 02:44 PM, Gregory Haskins wrote:
> The problem isn't where to find the models...the problem is how to
> aggregate multiple models to the guest.
>
You mean configuration?
>> You instantiate multiple vhost-nets. Multiple ethernet NICs is a
>> supported configuration for kvm.
>>
Avi Kivity wrote:
> On 09/15/2009 11:08 PM, Gregory Haskins wrote:
>>
>>> There's virtio-console, virtio-blk etc. None of these have kernel-mode
>>> servers, but these could be implemented if/when needed.
>>>
>> IIUC, Ira already needs at least ethernet and console capability.
>>
>>
>
>
On 09/15/2009 11:08 PM, Gregory Haskins wrote:
>
>> There's virtio-console, virtio-blk etc. None of these have kernel-mode
>> servers, but these could be implemented if/when needed.
>>
> IIUC, Ira already needs at least ethernet and console capability.
>
>
He's welcome to pick up the ne
Michael S. Tsirkin wrote:
> On Tue, Sep 15, 2009 at 05:39:27PM -0400, Gregory Haskins wrote:
>> Michael S. Tsirkin wrote:
>>> On Tue, Sep 15, 2009 at 04:43:58PM -0400, Gregory Haskins wrote:
Michael S. Tsirkin wrote:
> On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
>>
On Tue, Sep 15, 2009 at 05:39:27PM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Tue, Sep 15, 2009 at 04:43:58PM -0400, Gregory Haskins wrote:
> >> Michael S. Tsirkin wrote:
> >>> On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
> No, what I mean is how do yo
Michael S. Tsirkin wrote:
> On Tue, Sep 15, 2009 at 04:43:58PM -0400, Gregory Haskins wrote:
>> Michael S. Tsirkin wrote:
>>> On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
No, what I mean is how do you surface multiple ethernet and consoles to
the guests? For Ira's cas
On Tue, Sep 15, 2009 at 04:43:58PM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
> >> No, what I mean is how do you surface multiple ethernet and consoles to
> >> the guests? For Ira's case, I think he needs at minimu
Michael S. Tsirkin wrote:
> On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
>> No, what I mean is how do you surface multiple ethernet and consoles to
>> the guests? For Ira's case, I think he needs at minimum at least one of
>> each, and he mentioned possibly having two unique et
On Tue, Sep 15, 2009 at 04:08:23PM -0400, Gregory Haskins wrote:
> No, what I mean is how do you surface multiple ethernet and consoles to
> the guests? For Ira's case, I think he needs at minimum at least one of
> each, and he mentioned possibly having two unique ethernets at one point.
>
> His
Avi Kivity wrote:
> On 09/15/2009 04:50 PM, Gregory Haskins wrote:
>>> Why? vhost will call get_user_pages() or copy_*_user() which ought to
>>> do the right thing.
>>>
>> I was speaking generally, not specifically to Ira's architecture. What
>> I mean is that vbus was designed to work with
On 09/15/2009 04:50 PM, Gregory Haskins wrote:
>> Why? vhost will call get_user_pages() or copy_*_user() which ought to
>> do the right thing.
>>
> I was speaking generally, not specifically to Ira's architecture. What
> I mean is that vbus was designed to work without assuming that the
> m
On Tue, Sep 15, 2009 at 09:50:39AM -0400, Gregory Haskins wrote:
> Avi Kivity wrote:
> > On 09/15/2009 04:03 PM, Gregory Haskins wrote:
> >>
> >>> In this case the x86 is the owner and the ppc boards use translated
> >>> access. Just switch drivers and device and it falls into place.
> >>>
> >>>
Avi Kivity wrote:
> On 09/15/2009 04:03 PM, Gregory Haskins wrote:
>>
>>> In this case the x86 is the owner and the ppc boards use translated
>>> access. Just switch drivers and device and it falls into place.
>>>
>>>
>> You could switch vbus roles as well, I suppose.
>
> Right, there's not
On 09/15/2009 04:03 PM, Gregory Haskins wrote:
>
>> In this case the x86 is the owner and the ppc boards use translated
>> access. Just switch drivers and device and it falls into place.
>>
>>
> You could switch vbus roles as well, I suppose.
Right, there's not real difference in this regar
Avi Kivity wrote:
> On 09/14/2009 10:14 PM, Gregory Haskins wrote:
>> To reiterate, as long as the model is such that the ppc boards are
>> considered the "owner" (direct access, no translation needed) I believe
>> it will work. If the pointers are expected to be owned by the host,
>> then my mode
On 09/14/2009 10:14 PM, Gregory Haskins wrote:
> To reiterate, as long as the model is such that the ppc boards are
> considered the "owner" (direct access, no translation needed) I believe
> it will work. If the pointers are expected to be owned by the host,
> then my model doesn't work well eith
On 09/14/2009 07:47 PM, Michael S. Tsirkin wrote:
> On Mon, Sep 14, 2009 at 12:08:55PM -0400, Gregory Haskins wrote:
>
>> For Ira's example, the addresses would represent a physical address on
>> the PCI boards, and would follow any kind of relevant rules for
>> converting a "GPA" to a host acc
Michael S. Tsirkin wrote:
> On Mon, Sep 14, 2009 at 12:08:55PM -0400, Gregory Haskins wrote:
>> Michael S. Tsirkin wrote:
>>> On Fri, Sep 11, 2009 at 12:00:21PM -0400, Gregory Haskins wrote:
FWIW: VBUS handles this situation via the "memctx" abstraction. IOW,
the memory is not assumed to
Michael S. Tsirkin wrote:
> On Mon, Sep 14, 2009 at 12:08:55PM -0400, Gregory Haskins wrote:
>> For Ira's example, the addresses would represent a physical address on
>> the PCI boards, and would follow any kind of relevant rules for
>> converting a "GPA" to a host accessible address (even if indir
On Mon, Sep 14, 2009 at 12:08:55PM -0400, Gregory Haskins wrote:
> Michael S. Tsirkin wrote:
> > On Fri, Sep 11, 2009 at 12:00:21PM -0400, Gregory Haskins wrote:
> >> FWIW: VBUS handles this situation via the "memctx" abstraction. IOW,
> >> the memory is not assumed to be a userspace address. Rat
On Mon, Sep 14, 2009 at 12:08:55PM -0400, Gregory Haskins wrote:
> For Ira's example, the addresses would represent a physical address on
> the PCI boards, and would follow any kind of relevant rules for
> converting a "GPA" to a host accessible address (even if indirectly, via
> a dma controller).
Michael S. Tsirkin wrote:
> On Fri, Sep 11, 2009 at 12:00:21PM -0400, Gregory Haskins wrote:
>> FWIW: VBUS handles this situation via the "memctx" abstraction. IOW,
>> the memory is not assumed to be a userspace address. Rather, it is a
>> memctx-specific address, which can be userspace, or any o
virtualization@lists.linux-foundation.org; k...@vger.kernel.org;
> linux-ker...@vger.kernel.org; mi...@elte.hu; linux...@kvack.org;
> a...@linux-foundation.org; h...@zytor.com; gregory.hask...@gmail.com; Rusty
> Russell; s.he...@linux-ag.com; a...@redhat.com
> Subject: Re: [PATCHv5 3/3] vho
.@vger.kernel.org;
virtualization@lists.linux-foundation.org; k...@vger.kernel.org;
linux-ker...@vger.kernel.org; mi...@elte.hu; linux...@kvack.org;
a...@linux-foundation.org; h...@zytor.com; gregory.hask...@gmail.com; Rusty
Russell; s.he...@linux-ag.com; a...@redhat.com
Subject: Re: [PATCHv5 3/3] vhost_ne
On Fri, Sep 11, 2009 at 12:00:21PM -0400, Gregory Haskins wrote:
> FWIW: VBUS handles this situation via the "memctx" abstraction. IOW,
> the memory is not assumed to be a userspace address. Rather, it is a
> memctx-specific address, which can be userspace, or any other type
> (including hardware
On Fri, Sep 11, 2009 at 11:17:33PM +0800, Xin, Xiaohui wrote:
> Michael,
> We are very interested in your patch and want to have a try with it.
> I have collected your 3 patches in kernel side and 4 patches in queue side.
> The patches are listed here:
>
> PATCHv5-1-3-mm-export-use_mm-unuse_mm-to-
Ira W. Snyder wrote:
> On Mon, Sep 07, 2009 at 01:15:37PM +0300, Michael S. Tsirkin wrote:
>> On Thu, Sep 03, 2009 at 11:39:45AM -0700, Ira W. Snyder wrote:
>>> On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
What it is: vhost net is a character device that can be used to r
Gregory Haskins wrote:
[snip]
>
> FWIW: VBUS handles this situation via the "memctx" abstraction. IOW,
> the memory is not assumed to be a userspace address. Rather, it is a
> memctx-specific address, which can be userspace, or any other type
> (including hardware, dma-engine, etc). As long a
dation.org;
k...@vger.kernel.org; linux-ker...@vger.kernel.org; mi...@elte.hu;
linux...@kvack.org; a...@linux-foundation.org; h...@zytor.com;
gregory.hask...@gmail.com; Rusty Russell; s.he...@linux-ag.com
Subject: Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
On Tue, Sep 08, 2009 at
On Tue, Sep 08, 2009 at 10:20:35AM -0700, Ira W. Snyder wrote:
> On Mon, Sep 07, 2009 at 01:15:37PM +0300, Michael S. Tsirkin wrote:
> > On Thu, Sep 03, 2009 at 11:39:45AM -0700, Ira W. Snyder wrote:
> > > On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> > > > What it is: vhost
On Mon, Sep 07, 2009 at 01:15:37PM +0300, Michael S. Tsirkin wrote:
> On Thu, Sep 03, 2009 at 11:39:45AM -0700, Ira W. Snyder wrote:
> > On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> > > What it is: vhost net is a character device that can be used to reduce
> > > the number
On Thu, Sep 03, 2009 at 11:39:45AM -0700, Ira W. Snyder wrote:
> On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> > What it is: vhost net is a character device that can be used to reduce
> > the number of system calls involved in virtio networking.
> > Existing virtio net code
On Thu, Aug 27, 2009 at 07:07:50PM +0300, Michael S. Tsirkin wrote:
> What it is: vhost net is a character device that can be used to reduce
> the number of system calls involved in virtio networking.
> Existing virtio net code is used in the guest without modification.
>
> There's similarity with
Hi, Michael
That's a great job. We are now working on support VMDq on KVM, and since the
VMDq hardware presents L2 sorting based on MAC addresses and VLAN tags, our
target is to implement a zero copy solution using VMDq. We stared from the
virtio-net architecture. What we want to proposal is to
ists.linux-foundation.org; k...@vger.kernel.org;
linux-ker...@vger.kernel.org; mi...@elte.hu; linux...@kvack.org;
a...@linux-foundation.org; h...@zytor.com; gregory.hask...@gmail.com
Subject: Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
On Monday 31 August 2009, Xin, Xiaohui wrote:
>
Hv5 3/3] vhost_net: a kernel-level virtio server
On 08/31/2009 02:42 PM, Xin, Xiaohui wrote:
> Hi, Michael
> That's a great job. We are now working on support VMDq on KVM, and since the
> VMDq hardware presents L2 sorting based on MAC addresses and VLAN tags, our
> target is to i
.kernel.org; mi...@elte.hu; linux...@kvack.org;
a...@linux-foundation.org; h...@zytor.com; gregory.hask...@gmail.com
Subject: Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
Avi Kivity wrote:
> On 08/31/2009 02:42 PM, Xin, Xiaohui wrote:
>> Hi, Michael
>> That's a great job.
Avi Kivity wrote:
> On 08/31/2009 02:42 PM, Xin, Xiaohui wrote:
>> Hi, Michael
>> That's a great job. We are now working on support VMDq on KVM, and
>> since the VMDq hardware presents L2 sorting based on MAC addresses
>> and VLAN tags, our target is to implement a zero copy solution using
>> VM
On 08/31/2009 02:42 PM, Xin, Xiaohui wrote:
> Hi, Michael
> That's a great job. We are now working on support VMDq on KVM, and since the
> VMDq hardware presents L2 sorting based on MAC addresses and VLAN tags, our
> target is to implement a zero copy solution using VMDq. We stared from the
> vi
On Monday 31 August 2009, Xin, Xiaohui wrote:
>
> Hi, Michael
> That's a great job. We are now working on support VMDq on KVM, and since the
> VMDq hardware presents L2 sorting
> based on MAC addresses and VLAN tags, our target is to implement a zero copy
> solution using VMDq.
I'm also interes
79 matches
Mail list logo
