linux-kernel - Re: [GIT PULL] Native Linux KVM tool for 3.1

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jul 2011 12:03:11 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	Alexander Graf <agraf@...e.de>, Pekka Enberg <penberg@...nel.org>,
	Jan Kiszka <jan.kiszka@....de>, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, gorcunov@...il.com, levinsasha928@...il.com,
	asias.hejun@...il.com, prasadjoshi124@...il.com
Subject: Re: [GIT PULL] Native Linux KVM tool for 3.1

* Avi Kivity <avi@...hat.com> wrote:

> On 07/25/2011 12:41 PM, Ingo Molnar wrote:

> > Look at tools/kvm/ - i cannot do anything useful without a Linux 
> > kernel under it. It's as deeply bound to the Linux kernel as it 
> > gets.
> 
> The actual code that interacts with the kernel is pretty small, and 
> will grow smaller (as a fraction) in time.

Look at the example i have given in my other mail, conceptual 
interaction goes beyond the strict KVM (and hardware) ABIs themselves 
- for every guest side driver there's a host side piece of 
functionality.

What we found is that there's real benefits from tools/kvm/hw/i8042.c 
using the same conventions and constants as 
drivers/input/serio/i8042.c.

The two pieces of code are obviously independent ABI-wise - but to 
developers working on both sides of the fence it's very useful to 
have the code look similar and familiar.

Some other pieces of code share library functionality between the 
kernel and tools/kvm/.

> > Then look at the actual drivers and interfaces within tools/kvm/. 
> > It's using the same symbols and conventions for 'guest' and 
> > 'host' side.
> >
> > Check out tools/kvm/hw/i8042.c and match it up with 
> > include/linux/serio.h and drivers/input/serio/i8042.c - you can 
> > literally walk from one side to the other and understand how 
> > guest and host are tightly related not just functionality but 
> > also implementation wise.
> >
> > This is how Qemu should be doing it as well btw., to ease the 
> > debugging of host/guest interaction bugs and to ease development.
> 
> No. That ties the guest and host interfaces together. [...]

Why would it tie the interfaces together? For a guest and host driver 
to be written in the same familiar conventions is useful for 
debugging and development easier but does not prevent both of those 
pieces to implement a precise interface. (Especially since in the 
i8042 case the host driver is used with real hardware as well.)

> [...]  If you change the guest to use a feature you didn't 
> implement previously in the host, it's suddenly broken when 
> virtualized.
> 
> The right thing is to implement the hardware interface exactly per 
> spec, and ignore the guest(s) completely except for testing and 
> performance.

You can certainly do that too - and nothing prevents from the guest 
and host driver to look and feel similar.

But note that for many of these things there no such thing as a 
'hardware spec' that describes all the details and quirks - what we 
have are host PC drivers that have been implemented via many cycles 
of trial and error. That's especially true of i8042, the example i 
have given.

Thanks,

	Ingo
--
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/