linux-kernel - Re: [ANNOUNCE] Native Linux KVM tool

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:	Sun, 03 Apr 2011 12:17:08 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Pekka Enberg <penberg@...nel.org>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	linux-kernel@...r.kernel.org, aarcange@...hat.com,
	mtosatti@...hat.com, kvm@...r.kernel.org, joro@...tes.org,
	penberg@...helsinki.fi, asias.hejun@...il.com, gorcunov@...il.com,
	mingo@...e.hu
Subject: Re: [ANNOUNCE] Native Linux KVM tool

On 04/03/2011 11:51 AM, Pekka Enberg wrote:
> Hi Anthony,
>
> On Sat, Apr 2, 2011 at 11:38 PM, Anthony Liguori<anthony@...emonkey.ws>  wrote:
> >>  The goal of this tool is to provide a clean, from-scratch, lightweight
> >>  KVM host tool implementation that can boot Linux guest images (just a
> >>  hobby, won't be big and professional like QEMU) with no BIOS
> >>  dependencies and with only the minimal amount of legacy device
> >>  emulation.
> >
> >  I see you do provide 16-bit entry points for Linux.  Are you planning on
> >  paravirtualizing this within Linux to truly eliminate the BIOS dependency?
>
> No, we aren't planning that at the moment. We're trying to support
> out-of-the-box distro kernels when possible which is why we went for
> E820 emulation in the first place. The only hard requirement for
> bootung userspace is CONFIG_VIRTIO_BLK but otherwise kernel binaries
> should just work.
>
> Furthermore, as the BIOS glue is really really small, I'm not sure if
> we need to get rid of it completely. Do you have some scenario in mind
> where paravirt solution would help?

It would be a easier to support the bios than implement everything it 
provides in a different way.  SMP support, cpu hotplug, device hotplug, 
NUMA, and probably other features all rely on the bios.

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