linux-kernel - Re: [Xen-devel] Re: [PATCH v4 00/10] xen: initial domain support

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]

Message-ID: <4CBE139E.3060004@goop.org>
Date:	Tue, 19 Oct 2010 14:54:38 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Greg KH <greg@...ah.com>
CC:	Stefano Stabellini <Stefano.Stabellini@...citrix.com>,
	Jeremy Fitzhardinge <Jeremy.Fitzhardinge@...rix.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] Re: [PATCH v4 00/10] xen: initial domain support

 On 10/19/2010 02:14 PM, Greg KH wrote:
> On Tue, Oct 19, 2010 at 12:16:31PM +0100, Stefano Stabellini wrote:
>> Hi all,
>> this series implements the basic support needed to boot Linux as initial
>> domain on Xen: the target is not to add full featured dom0 support in
>> the kernel but to be able to boot Linux on Xen on native.
> Nice, but what real use is this?
>
> I thought people wanted dom0 support, this doesn't seem to give them
> that.  Is that still the end-goal here, and this is merely a
> stepping-stone to get there?

Yes, it's a significant step there.  Once that's merged the main missing
piece is backend drivers, which we can probably get into a mergable form
for the next window.  And in the meantime, they're a fairly
self-contained thing to maintain out of tree (like other drivers).

Our strategy has been to put together a cluster of patch series which
each have their own intrinsic value, but are also all leading to full
dom0 support.  For example, Stefano's pv-hvm patches are useful for
running Linux as a fully virtualized domain under Xen, but the reworking
of the interrupt infrastructure in a way that dom0 support requires. 
Likewise, Konrad's work on pci-passthrough for domU domains adds all the
machinery required for a Xen domain to have direct access to hardware,
which is also what dom0 requires.

This particular series introduces the pieces needed for the kernel to
actually boot up to usermode as dom0, which has some value even if it
doesn't yet allow you to start new domains (well, you could, but they
wouldn't have any devices).

The net result is that there will be no massive "Xen dom0" patch series,
since that has been pretty clearly rejected in the past.  Instead full
dom0 support is being implemented - at least to some extent - as the
emergent result of a number of Xen-related patches.  These patches also
touch very little code outside of the existing Xen codebase, so there
shouldn't be much scope for controversy.

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