lkml.org 
[lkml]   [2006]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/7] KVM: Kernel-based Virtual Machine
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-10-22 18:21    [W:0.208 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site