On Tue, Sep 03, 2013 at 11:55:56AM +0300, Michael S. Tsirkin wrote:

On Tue, Sep 03, 2013 at 09:40:48AM +0100, Wei Liu wrote:

quoted

On Tue, Sep 03, 2013 at 09:28:11AM +0800, Qin Chuanyu wrote:

quoted

On 2013/9/2 15:57, Wei Liu wrote:

quoted

On Sat, Aug 31, 2013 at 12:45:11PM +0800, Qin Chuanyu wrote:

quoted

On 2013/8/30 0:08, Anthony Liguori wrote:

quoted

Hi Qin,

quoted

quoted

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.

quoted

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.

There is nothing technically stopping driver domains to work. It's about
the boundary of trust.

quoted

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.

XSM is there already, someone in a while might just want to give it a
shot despite it's not well supported. Then all of a sudden they find out
something works before (the foreign mapping backend) would not work
anymore. That would just lead to confusion. It's like a cycle of bad
things. Users try something lack of support -> it doesn't work -> users
won't use it anymore -> less support because nobody seems to be
interested.

quoted

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.

I'm not sure direct access will be faster. Either way hypervisor is
involved to update guest's page table.

Anyway, my point is, switching to grant table is not as hard as you
think - pass along grant refs instead of guest pseudo address in the
ring and use grant table API instead of foreign mapping API in the
backend.

Wei.

quoted

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html