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

RE: [Xen-devel] [PATCH]vbd/vnif paravirtulization driver hypervisorsupport]

  • To: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • From: "Ling, Xiaofeng" <xiaofeng.ling@xxxxxxxxx>
  • Date: Wed, 25 May 2005 14:26:40 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 25 May 2005 06:26:12 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcVdBMqGMA2IEEsTSdm26uwqvN7GUwDyn0KwAAWzq3AAAnzmcA==
  • Thread-topic: [Xen-devel] [PATCH]vbd/vnif paravirtulization driver hypervisorsupport]

Ian Pratt <mailto:m+Ian.Pratt@xxxxxxxxxxxx> wrote:
>> Is there any comment for this patch?
>> Is it acceptable or not?
> I think it needs a more work. Using grant tables should help unify
The grant table support is already in for vbd. and without grant table
configuration can also work.

> things. I'm convinced that you're missing out on some unifying
> paradigm that will cause many of the "if(VMX_DOMAIN(current))"
> clauses to evaporate.   
Most of the VMX_DOMAIN is used for copy_to/from_user, __get_user/__put_user
Because VMX domain has separate address space. these function can not be used 
I've add a condition in copy_to/from_user, but some place, it uses separated 
array_access_ok  and __copy_to/from_user. 
For  __get_user/__put_user, in some place, that can still be used, like linear 
page table, some place,
that must be replaced with copy_to/from_guest.
So do you have better idea to deal with these things?
Or we use shadow_mode_external() to separate the path?

Xen-devel mailing list



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