Re: [PATCH 00 of 27] Refactor libkvm code Phase 1

[Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Hmm,
	The problem here is in the case of kvm_create_phys_mem &
kvm_create_default_phys_mem, most archs from now on should always be
allocating guest memory from userspace (at least I think this correct).

	Now if this is not the case then really adding an architecture hook
function to kvm_create_default_phys_mem would also solve this problem.
As There is a mmap call that maps memory for video(?), which is
something that is just for x86.

	With the size of these functions being very small, I think it's best to
move them for now. Then if someone else does need them they can easily
create there own and then we can figure out how to make a common
function in this case.

	Anyone disagree?

  
On Fri, 2007-11-02 at 13:26 +0800, Zhang, Xiantao wrote:
> Hi Young, 
> 	Quick hand! For patch 07/27, 09/27, i have some concerns about them.  In these two patches you moved the functions kvm_create_kernel_phys_mem, kvm_create_default_phys_mem to x86 arch. But I think it should work well for most archs. As somebody said, S390 may have a very different memory allocation mechanism, but we can't move them directly to x86 arch, because other archs may also need them.  We should find another approach to handle them, and make s390 and other archs all happy ! What about your ideas?:)
> thanks 
> Xiantao
> 
> -----Original Message-----
> From: kvm-devel-bounces@lists.sourceforge.net [mailto:kvm-devel-bounces@lists.sourceforge.net] On Behalf Of Jerone Young
> Sent: 2007年11月1日 1:05
> To: kvm-devel@lists.sourceforge.net
> Cc: kvm-ppc-devel@lists.sourceforge.net
> Subject: [kvm-devel] [PATCH 00 of 27] Refactor libkvm code Phase 1
> 
> Kaniciwa!
>         I am here to once again bring great honorable patches to refactor
> libkvm x86 code. Patches that I sent in the past for this really took
> the wrong approach, and also many variables that I was splitting out actually
> could be shared amongst many architectures.
> 
>         This is the first phase as much of the code is tightly written for x86 
> but can be reused by other archs, it's just a matter of an agreed upon method.
> Also since there are about 27 of these lets get through these before moving
> through more.
> 
> Signed-off-by: Jerone Young <jyoung5@us.ibm.com>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel