[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Is fallback vhost_net to qemu for live migrate availableï
On Tue, Sep 03, 2013 at 09:40:48AM +0100, Wei Liu wrote: > On Tue, Sep 03, 2013 at 09:28:11AM +0800, Qin Chuanyu wrote: > > On 2013/9/2 15:57, Wei Liu wrote: > > >On Sat, Aug 31, 2013 at 12:45:11PM +0800, Qin Chuanyu wrote: > > >>On 2013/8/30 0:08, Anthony Liguori wrote: > > >>>Hi Qin, > > >> > > >>>>By change the memory copy and notify mechanism ïcurrently virtio-net > > >>>>with > > >>>>vhost_net could run on Xen with good performanceã > > >>> > > >>>I think the key in doing this would be to implement a property > > >>>ioeventfd and irqfd interface in the driver domain kernel. Just > > >>>hacking vhost_net with Xen specific knowledge would be pretty nasty > > >>>IMHO. > > >>> > > >>Yes, I add a kernel module which persist virtio-net pio_addr and > > >>msix address as what kvm module did. Guest wake up vhost thread by > > >>adding a hook func in evtchn_interrupt. > > >> > > >>>Did you modify the front end driver to do grant table mapping or is > > >>>this all being done by mapping the domain's memory? > > >>> > > >>There is nothing changed in front end driver. Currently I use > > >>alloc_vm_area to get address spaceï and map the domain's memory as > > >>what what qemu did. > > >> > > > > > >You mean you're using xc_map_foreign_range and friends in the backend to > > >map guest memory? That's not very desirable as it violates Xen's > > >security model. It would not be too hard to pass grant references > > >instead of guest physical memory address IMHO. > > > > > In fact, I did what virtio-net have done in Qemu. I think security > > is a pseudo question because Dom0 is under control. > > > > Consider that you might have driver domains. Not every domain is under > control or trusted. I don't see anything that will prevent using driver domains here. > Also consider that security model like XSM can be > used to audit operations to enhance security so your foreign mapping > approach might not always work. It could be nice to have as an option, sure. XSM is disabled by default though so I don't think lack of support for that makes it a prototype. > In short term foreign mapping can save you some time implementing the > prototype. > In long term using grant table is the proper way to go. And > IMHO the benifit outweights the cost. > > Wei. I'm guessing direct access could be quite a bit faster. But someone would have to implement your idea in order to do a cost/benefit analysis. > > Host could access memory of guest in KVM much easier than Xen, > > but I hadn't heard someone said KVM is un-secret. > > > > Regards > > Qin chuanyu > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe netdev" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |