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.
This way you can simply kill a task, which also cleans up
all the special objects it allocated.
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.
> | | # 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.
> |
> |
> +----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.
> +----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.
Arnd <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
