Prev: Announce loop-AES-v3.3a file/swap crypto package
Next: [PATCH] OMAP: Devkit8000: Add missing package selection
From: Avi Kivity on 22 Mar 2010 14:10
On 03/22/2010 06:40 PM, Pekka Enberg wrote:
> On Mon, Mar 22, 2010 at 6:16 PM, Avi Kivity<avi(a)redhat.com> wrote:
>
>>> You simply kept ignoring me when I said that if something can be kept out
>>> of the kernel without impacting performance, it should be. I don't want
>>> emergency patches closing some security hole or oops in a kernel symbol
>>> server.
>>>
>> Or rather, explained how I am a wicked microkernelist. The herring were out
>> in force today.
>>
> Well, if it's not being a "wicked microkernelist" then what is it?
>

I know I'm bad.

> Performance is hardly the only motivation to put things into the
> kernel. Think kernel mode-setting and devtmpfs (with the ironic twist
> of original devfs being removed from the kernel) here, for example.
>

Motivations include privileged device access, needing to access physical
memory, security, and keeping the userspace interface sane. There are
others. I don't think any of them hold here.

--
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 22 Mar 2010 14:20
On Mon, Mar 22, 2010 at 8:04 PM, Avi Kivity <avi(a)redhat.com> wrote:
>> That said, pulling 400 KLOC of code into the kernel sounds really
>> excessive. Would we need all that if we just do native virtualization
>> and no actual emulation?
>
> What is native virtualization and no actual emulation?

What I meant with "actual emulation" was running architecture A code
on architecture B what was qemu's traditional use case. So the
question was how much of the 400 KLOC do we need for just KVM on all
the architectures that it supports?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Avi Kivity on 22 Mar 2010 15:00
On 03/22/2010 08:10 PM, Pekka Enberg wrote:
> On Mon, Mar 22, 2010 at 8:04 PM, Avi Kivity<avi(a)redhat.com> wrote:
>
>>> That said, pulling 400 KLOC of code into the kernel sounds really
>>> excessive. Would we need all that if we just do native virtualization
>>> and no actual emulation?
>>>
>> What is native virtualization and no actual emulation?
>>
> What I meant with "actual emulation" was running architecture A code
> on architecture B what was qemu's traditional use case. So the
> question was how much of the 400 KLOC do we need for just KVM on all
> the architectures that it supports?
>

qemu is 620 KLOC. Without cpu emulation that drops to ~480 KLOC. Much
of that is device emulation that is not supported by kvm now (like ARM)
but some might be needed again in the future (like ARM).

x86-only is perhaps 300 KLOC, but kvm is not x86 only.

And that is with a rudimentary GUI. GUIs are heavy.

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Javier Guerra Giraldez on 23 Mar 2010 15:10
On Tue, Mar 23, 2010 at 2:21 PM, Joerg Roedel <joro(a)8bytes.org> wrote:
> On Tue, Mar 23, 2010 at 06:39:58PM +0200, Avi Kivity wrote:
>> So, two users can't have a guest named MyGuest each?  What about
>> namespace support?  There's a lot of work in virtualizing all kernel
>> namespaces, you're adding to that.
>
> This enumeration is a very small and non-intrusive feature. Making it
> aware of namespaces is easy too.

an outsider's comment: this path leads to a filesystem... which could
be a very nice idea. it could have a directory for each VM, with
pseudo-files with all the guest's status, and even the memory it's
using. perf could simply watch those files. in fact, such a
filesystem could be the main userleve/kernel interface.

but i'm sure such a layour was considered (and rejected) very early in
the KVM design. i don't think there's anything new to make it more
desirable than it was back then.


--
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2 3
Prev: Announce loop-AES-v3.3a file/swap crypto package
Next: [PATCH] OMAP: Devkit8000: Add missing package selection