[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] problem with netfront.c


  • To: "Ling, Xiaofeng" <xiaofeng.ling@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Sun, 3 Apr 2005 16:33:41 +0100
  • Delivery-date: Sun, 03 Apr 2005 15:34:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcU39PebD2/thBv+Rdms3itvtFiuwQAPExGgAAL3ilAAA/XnwAADDtQwAAG+UBA=
  • Thread-topic: [Xen-devel] problem with netfront.c

> > Using grant tables, the front end doesn't need to know 
> about machine 
> > addresses, and the whole thing ends up rather cleaner, 
> particulary for 
> > domains running with virtualized VMs.
> Yes, there do have security problem to use machine address in 
> netfront.

It's not actually a security problem, but using mfns is a bit ugly.

> I'm originally  thinking that we can pass virtual address to 
> backend through the ring buffer and let the backend to set 
> the mapping for the frontend. 
> I've already done a blkfront module driver in unmodified 
> linux with an event channel channel  and ctrlif module 
> driver. 

Great.

> I'll wait for the new blkfront with grant table. For 
> netfront, if no one has worked on the grant table update, I 
> can do it together.

I've attached the patch that updates the grant tables code and switches
the blk dev over to use it.

It would be great if you could workup something similar up for the
netfront/back.

Thanks,
Ian

Attachment: block-over-gnttab.patch
Description: block-over-gnttab.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.