Re: [PATCH/PFC 0/2] s390 host support

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Carsten Otte wrote:
>
>> The address space and vcpu management are rather different from kvm's,
>> however your approach is better and we'll want to move kvm in your
>> direction rather than the other way round (specifically the tight vcpu
>> <-> task coupling; mmu is more diffcult).
> We have tried a file based approach for the cpus before too.

We'll want to keep a vcpu fd.  If the vcpu is idle we'll be asleep in 
poll() or the like, and we need some kind of wakeup mechanism.

>
> With regard to the memory, I do not quite understand why regular 
> pageable user space memory does'nt work with vt and svm. We would 
> definetly prefer to keep our virtual machine's memory pageable on 
> s390, therefore I guess we need some arch dependent plug that 
> allocates the memory. This would boil down to a regular anonymous 
> allocation on s390, and to specifically allocated memory on x86.

I guess some of the difference stems from the fact that on x86, the 
Linux pagetables are actually the hardware pagetables.  VT and SVM use a 
separate page table for the guest which cannot be shared with the host. 
This means that

- we need to teach the Linux mm to look at shadow page tables when 
transferring dirty bits
- when Linux wants to write protect a page, it has to modify the shadow 
page tables too (and flush the guest tlbs, which is again a bit different)
- this means rmap has to be extended to include kvm

I think that non-x86 have purely software page tables, maybe this make 
things easier.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/