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.
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. Those refinements will be posted later.
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 those who provided early feedback to this patchset: Andi Kleen,
Gerd Hoffmann, Jan Beulich, Rik van Riel, Stephen Tweedie, and the Xen team.
And thanks to the Xen community: AMD, HP, IBM, Intel, Novell, Red Hat,
Virtual Iron, XenSource -- see Xen changelog for full details.
Known issues:
CodingStyle conformance is still in progress
/proc interface needs to be replaced with something more appropriate
entry.S cleanups are possible
Chris Wright wrote:
> Xen also provides support for running directly on native hardware.
>
Can someone elaborate on this? Does this mean a Xen guest can run on
bare metal?
Is there code available to make this work (it doesn't seem contained in
this patchset)? Has any performance analysis been done?
The numbers that have been posted with the VMI patches suggest that some
rather tricky stuff is required to achieve native performance when
running a guest on bare metal. If this is not the case, it would be
very interesting to know because it seems to be the hairiest part of the
VMI patches.
Otherwise, if we want to support Xen guests on bare metal, it seems we
would have to change things in the subarch code a bit to do something
similar to VMI.
Regards,
Anthony Liguori
> 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.
>
> 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. Those refinements will be posted later.
>
> 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 those who provided early feedback to this patchset: Andi Kleen,
> Gerd Hoffmann, Jan Beulich, Rik van Riel, Stephen Tweedie, and the Xen team.
> And thanks to the Xen community: AMD, HP, IBM, Intel, Novell, Red Hat,
> Virtual Iron, XenSource -- see Xen changelog for full details.
>
> Known issues:
>
> CodingStyle conformance is still in progress
> /proc interface needs to be replaced with something more appropriate
> entry.S cleanups are possible
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Virtualization mailing list
> [email protected]
> https://lists.osdl.org/mailman/listinfo/virtualization
>
* Anthony Liguori ([email protected]) wrote:
> Chris Wright wrote:
> >Xen also provides support for running directly on native hardware.
>
> Can someone elaborate on this? Does this mean a Xen guest can run on
> bare metal?
Yes. See the Xen code for running the kernel in ring0 with Xen
(supervisor_mode_kenel). The hypercall_page is conditionally filled
with hypercall traps or direct calls basically.
> Is there code available to make this work (it doesn't seem contained in
> this patchset)? Has any performance analysis been done?
I don't have any numbers.
> The numbers that have been posted with the VMI patches suggest that some
> rather tricky stuff is required to achieve native performance when
> running a guest on bare metal. If this is not the case, it would be
> very interesting to know because it seems to be the hairiest part of the
> VMI patches.
It is a hairy part of VMI. They've done a nice job of handling the
native case, and have interseting plans for improving the non-native
case (inline where possible). One of the differences is things that
don't actually require hypercalls are already inline w/ Xen. So it's
conceivable that the performance hit is smaller than what VMI found
without carefully inlining native code.
> Otherwise, if we want to support Xen guests on bare metal, it seems we
> would have to change things in the subarch code a bit to do something
> similar to VMI.
It's a different approach.
thanks,
-chris
Chris Wright wrote:
> * Anthony Liguori ([email protected]) wrote:
>
>> Chris Wright wrote:
>>
>>> Xen also provides support for running directly on native hardware.
>>>
>> Can someone elaborate on this? Does this mean a Xen guest can run on
>> bare metal?
>>
>
> Yes. See the Xen code for running the kernel in ring0 with Xen
> (supervisor_mode_kenel). The hypercall_page is conditionally filled
> with hypercall traps or direct calls basically.
>
Cool! I didn't realize the supervisor_mode_kernel code was in the Xen
tree code already.
Regards,
Anthony Liguori
>> Is there code available to make this work (it doesn't seem contained in
>> this patchset)? Has any performance analysis been done?
>>
>
> I don't have any numbers.
>
>
>> The numbers that have been posted with the VMI patches suggest that some
>> rather tricky stuff is required to achieve native performance when
>> running a guest on bare metal. If this is not the case, it would be
>> very interesting to know because it seems to be the hairiest part of the
>> VMI patches.
>>
>
> It is a hairy part of VMI. They've done a nice job of handling the
> native case, and have interseting plans for improving the non-native
> case (inline where possible). One of the differences is things that
> don't actually require hypercalls are already inline w/ Xen. So it's
> conceivable that the performance hit is smaller than what VMI found
> without carefully inlining native code.
>
>
>> Otherwise, if we want to support Xen guests on bare metal, it seems we
>> would have to change things in the subarch code a bit to do something
>> similar to VMI.
>>
>
> It's a different approach.
>
> thanks,
> -chris
>