Re: [PATCH 0/7] KVM: Kernel-based Virtual Machine

[Avi Kivity <avi@qumranet.com>]

Arnd Bergmann wrote:
> On Sunday 22 October 2006 10:37, Avi Kivity wrote:
>   
>> I like this.  Since we plan to support multiple vcpus per vm, the fs
>> structure might look like:
>>
>> /kvm/my_vm
>>     |
>>     +----memory          # mkdir to create memory slot.
>>     
>
> Note that the way spufs does it, every directory is a reference-counted
> object. Currently that includes single contexts and groups of
> contexts that are supposed to be scheduled simultaneously.
>
> The trick is that we use the special 'spu_create' syscall to
> add a new object, while naming it, and return an open file
> descriptor to it. When that file descriptor gets closed, the
> object gets garbage-collected automatically.
>   

Yes.  Well, a single fd and ioctl()s do that as well.

>
> We ended up adding a lot more file than we initially planned,
> but the interface is really handy, especially if you want to
> create some procps-like tools for it.
>
>   

I don't really see the need.  The cell dsps are a shared resource, while 
virtual machines are just another execution mode of an existing resource 
- the main cpu, which has a sharing mechanism (the scheduler and 
priorities).


>>     |     |              #    how to set size and offset?
>>     |     |
>>     |     +---0          # guest physical memory slot
>>     |         |
>>     |         +-- dirty_bitmap  # read to get and atomically reset
>>     |                           # the changed pages log
>>     
>
> Have you thought about simply defining your guest to be a section
> of the processes virtual address space? That way you could use
> an anonymous mapping in the host as your guest address space, or
> even use a file backed mapping in order to make the state persistant
> over multiple runs. Or you could map the guest kernel into the
> guest real address space with a private mapping and share the
> text segment over multiple guests to save L2 and RAM.
>   

I've thought of it but it can't work on i386 because guest physical 
address space is larger than virtual address space on i386.  So we 
mmap("/dev/kvm") with file offsets corresponding to guest physical 
addresses.

I still like that idea, since it allows using hugetlbfs and allowing 
swapping.  Perhaps we'll just accept the limitation that guests on i386 
are limited.

>   
>>     |
>>     |
>>     +----cpu             # mkdir/rmdir to create/remove vcpu
>>           |
>>     
>
> I'd recommend not allowing mkdir or similar operations, although
> it's not that far off. One option would be to let the user specify
> the number of CPUs at kvm_create() time, another option might
> be to allow kvm_create with a special flag or yet another syscall
> to create the vcpu objects.
>   

Okay.

>   
>>           +----0
>>           |     |
>>           |     +--- irq     # write to inject an irq
>>           |     |
>>           |     +--- regs    # read/write to get/set registers
>>           |     |
>>           |     +--- debugger   # write to set breakpoints/singlestep mode
>>           |
>>           +----1
>>                 [...]
>>
>> It's certainly a lot more code though, and requires new syscalls.  Since
>> this is a little esoteric does it warrant new syscalls?
>>     
>
> We've gone through a number of iterations on the spufs design regarding this,
> and in the end decided that the garbage-collecting property of spu_create
> was superior to any other option, and adding the spu_run syscall was then
> the logical step. BTW, one inspiration for spu_run came from sys_vm86, which
> as you are probably aware of is already doing a lot of what you do, just
> not for protected mode guests.
>   

Yes, we're doing a sort of vmx86_64().

Thanks for the ideas, I'm certainly leaning towards a filesystem based 
approach and I'll also reconsider the mapping (mmap() vi virtual address 
space subsection).

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