Unlike full virtualization in which the virtual machine provides
the same platform interface as running natively on the hardware,
paravirtualization requires modification to the guest operating system
to work with the platform interface provided by the hypervisor.
Xen was designed with performance in mind. Calls to the hypervisor
are minimized, batched if necessary, and non-critical codepaths are left
unmodified in the case where the privileged instruction can be trapped and
emulated by the hypervisor. The Xen API is designed to be OS agnostic and
has had Linux, NetBSD, FreeBSD, Solaris, Plan9 and Netware ported to it.
Xen also provides support for running directly on native hardware.
The following patch series provides the minimal support required to
launch Xen paravirtual guests on standard x86 hardware running the Xen
hypervisor. These patches effectively port the Linux kernel to run on the
platform interface provided by Xen. This port is done as an i386 subarch.
In the future, we will break this patchset up to place the general
infrastrcture and subarch bits that may have common users at the
beginning of the series, ripe for picking off and pushing upstream.
With these patches you will be able to launch an unprivileged guest
running the modified Linux kernel and unmodified userspace. This guest
is x86, UP only, runs in shadow translated mode, and has no direct access
to hardware. This simplifies the patchset to the minimum functionality
needed to support a paravirtualized guest. It's worth noting that
a fair amount of this patchset deals with paravirtualizing I/O, not
just CPU-only. The additional missing functionality is primarily about
full SMP support, optimizations such as direct writable page tables,
and the management interface.
At a high-level, the patches provide the following:
- Kconfig and Makefile changes required to support Xen
- subarch changes to allow more platform functionality to be
implemented by an i386 subarch
- Xen subarch implementation
- start of day code for running in the hypervisor provided environment (paging
enabled)
- basic Xen drivers to provide a fully functional guest
The Xen platform API encapsulates the following types of requirements:
- idt, gdt, ldt (descriptor table handling)
- cr2, fpu_taskswitch, debug registers (privileged register handling)
- mmu (page table, tlb, and cache handling)
- memory reservations
- time and timer
- vcpu (init, up/down vcpu)
- schedule (processor yield, shutdown, etc)
- event channel (generalized virtual interrupt handling)
- grant table (shared memory interface for high speed interdomain communication)
- block device I/O
- network device I/O
- console device I/O
- Xen feature map
- Xen version info
Thanks to all have reviewed earlier versions of these patches.
-chris
--
Congrats on getting this thrashed out. A few comments, most of which are
boring style nits, but nonetheless ... will try to take a proper look
later.
General comment:
Why is this style used:
HYPERVISOR_foo_bar ?
ie the capitalization of HYPERVISOR. Doesn't seem to fit with the rest
of the kernel style.
On Tue, May 09, 2006 at 07:49:37AM -0700, Martin J. Bligh wrote:
> Congrats on getting this thrashed out. A few comments, most of which are
> boring style nits, but nonetheless ... will try to take a proper look
> later.
>
> General comment:
>
> Why is this style used:
>
> HYPERVISOR_foo_bar ?
>
> ie the capitalization of HYPERVISOR. Doesn't seem to fit with the rest
> of the kernel style.
It's also wrong. There's more than one hypervisor and Xen shouldn't just
grab this namespace. make it xen_ or xenhv_.
Christoph Hellwig wrote:
> On Tue, May 09, 2006 at 07:49:37AM -0700, Martin J. Bligh wrote:
>
>>Congrats on getting this thrashed out. A few comments, most of which are
>>boring style nits, but nonetheless ... will try to take a proper look
>>later.
>>
>>General comment:
>>
>>Why is this style used:
>>
>>HYPERVISOR_foo_bar ?
>>
>>ie the capitalization of HYPERVISOR. Doesn't seem to fit with the rest
>>of the kernel style.
>
>
> It's also wrong. There's more than one hypervisor and Xen shouldn't just
> grab this namespace. make it xen_ or xenhv_.
I think the intent was to create something generic enough for others to
use. There were other projects that already intended to use the same
model ... and please, lets not have one stack of this stuff for each
hypervisor. So in general, I think the approach is correct, I was just
whining about style stuff ;-)
M.
Christoph Hellwig <[email protected]> writes:
> On Tue, May 09, 2006 at 07:49:37AM -0700, Martin J. Bligh wrote:
> > Congrats on getting this thrashed out. A few comments, most of which are
> > boring style nits, but nonetheless ... will try to take a proper look
> > later.
> >
> > General comment:
> >
> > Why is this style used:
> >
> > HYPERVISOR_foo_bar ?
> >
> > ie the capitalization of HYPERVISOR. Doesn't seem to fit with the rest
> > of the kernel style.
>
> It's also wrong. There's more than one hypervisor and Xen shouldn't just
> grab this namespace. make it xen_ or xenhv_.
You should reject the recent "hypervisor file system" with the same
argument then.
-Andi
On Tue, May 09, 2006 at 05:20:11PM +0200, Andi Kleen wrote:
> > It's also wrong. There's more than one hypervisor and Xen shouldn't just
> > grab this namespace. make it xen_ or xenhv_.
>
> You should reject the recent "hypervisor file system" with the same
> argument then.
I prefer it would become lparfs or something like that indeed.
On Tue, May 09, 2006 at 05:20:11PM +0200, Andi Kleen wrote:
> > > It's also wrong. There's more than one hypervisor and Xen shouldn't just
> > > grab this namespace. make it xen_ or xenhv_.
> >
> > You should reject the recent "hypervisor file system" with the same
> > argument then.
On 5/9/06, Christoph Hellwig <[email protected]> wrote:
> I prefer it would become lparfs or something like that indeed.
AFAIK it's called s390-hypfs now.
Pekka
Christoph Hellwig <[email protected]> wrote:
>
> On Tue, May 09, 2006 at 05:20:11PM +0200, Andi Kleen wrote:
> > > It's also wrong. There's more than one hypervisor and Xen shouldn't just
> > > grab this namespace. make it xen_ or xenhv_.
> >
> > You should reject the recent "hypervisor file system" with the same
> > argument then.
>
> I prefer it would become lparfs or something like that indeed.
Yes, it did get renamed to something s390-specific.
Also, note
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/driver-core-add-sys-hypervisor-when-needed.patch
which creates the /sys/hypervisor directory. With the expectation that
_all_ hypervisorish subsystems will base their sysfs trees in there.
* Andrew Morton ([email protected]) wrote:
> Also, note
>
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver/driver-core-add-sys-hypervisor-when-needed.patch
>
> which creates the /sys/hypervisor directory. With the expectation that
> _all_ hypervisorish subsystems will base their sysfs trees in there.
That's fine, Xen is currently using the same dir, so we just need to
adjust and select Kconfig. There's some fallout as a a result (using
attrs directly vs spinning your own fs, for example), but it makes sense
to have common anchor in sysfs.
thanks,
-chris