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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerone Young
> Sent: 2007年11月1日 1:05
> To: kvm-devel@lists.sourceforge.net
> Cc: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
>
> -------------------------------------------------------------------------
> 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
