linux-kernel - Re: [PATCH -v2] Add MCE support to KVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <49EF227E.4020501@redhat.com>
Date:	Wed, 22 Apr 2009 16:58:22 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
CC:	Huang Ying <ying.huang@...el.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH -v2] Add MCE support to KVM

Anthony Liguori wrote:
> Avi Kivity wrote:
>>
>> The refactoring, absolutely.  But if I have kernel support for zero 
>> copy tomorrow, do I wait until qemu completes refactoring the VLAN 
>> API, or do I hack something in so I can test it and get the benefit 
>> to users?
>
> Why can't we do this in upstream QEMU though?  Part of the point I'm 
> trying to make here is that what QEMU is can be flexible.  

If we do it the right way, it takes time, and we serialize development 
(for example, we don't find and fix bugs in the kernel).
We don't want to do it the wrong way.

> We can find ways to include functionality that might not be ready for 
> prime time by making it conditionally compiled, only available when 
> using KVM, etc.  It's all open for discussion.  So I'll be quite blunt 
> about it, what needs to change about what QEMU takes and doesn't take 
> in order to get rid of kvm-userspace?

#ifdefs in master, an experimental branch, and kvm-userspace (soon, 
qemu-kvm) are all equivalent.

There's even an option to diff(1) to generate #ifdefs instead of the 
traditional diff markers.

> Experimentation is a good thing.  It's also important to do things the 
> right way as early as possible though because the longer users depend 
> on something, the harder it is to change later.  I think it's easier 
> to strike that balance in upstream QEMU than trying to port things 
> from kvm-userspace over to QEMU after the fact.

Well, let's take it on a case by case basis.  I certainly prefer to see 
everything go to qemu.git.  If we find a case where it isn't workable, 
qemu-kvm.git can be a temporary home.

> We can have KVM specific features in QEMU when that makes sense.  In 
> the case of MCE, it doesn't make any sense because it's relatively 
> simple and the implementation can be common given the right interfaces.

The kvm kernel module doesn't have common implementation for qemu/tcg 
and qemu/kvm as one of its goals.  It doesn't know anything about qemu.  
It wants to export an interface that makes sense (is as close to the cpu 
model as possible).

The few places that we inadvertently let qemuisms slip through turned 
out to be mistakes.

I agree that MCE is simple so it's easy to implement in both.  But the 
other features may be different.

-- 
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/