[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn
From: |
Stefano Stabellini |
Subject: |
Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn |
Date: |
Tue, 2 Nov 2010 19:20:19 +0000 |
User-agent: |
Alpine 2.00 (DEB 1167 2008-08-23) |
On Tue, 2 Nov 2010, Alexander Graf wrote:
> This is getting confusing :). There are multiple ways of spawning a Xen PV
> instance I'm aware of:
>
> 1) Xen PV context
> 2) Xen PV context in SVM/VMX container, maintained by Xen
> 3) Xenner on TCG/KVM
> 4) Xenner on Xen HVM
>
> For 1 and 2 the way to go is definitely to reuse the xen infrastructure. For
> 3 I'm very reluctant in requiring dependencies. One of qemu's strong points
> is that it does not have too many dependencies on other code. If there are
> strong points for it however, I gladly change my position :).
>
> For 4 however, I haven't fully made up my mind on if it's useful to people
> (if you say it is, I'm more than glad to get this rolling!) and what the best
> way to implement it would be.
>
I am guessing that with 2) you are referring to Linux PV on HVM guests.
If so 2) and 4) are very different: a Linux PV on HVM guest is a normal
Linux kernel that would boot just fine on native, but is also able to
enable some Xen PV interfaces when running in a Xen HVM domain.
Linux PV on HVM guests are new and support is in the kernel since less
than a year.
However Linux PV guests have been around for a long time and
traditionally are unable to boot on native or in a Xen HVM container.
So 4) would allow these kernels to boot in a Xen HVM container
unmodified, this is why it would be useful.
> So I suppose your suggestion is to use the xen infrastructure for case 4?
> That might work out. Fortunately, all the detection on which backend we use
> happens at runtime. Since in that case Xen does own the guest's memory, we
> might even be safe on using its memory mapping functionality. Maybe.
>
Yes. Case 4) is just a normal Xen HVM domain from the Xen point of view,
so it needs all the rest of the Xen infrastructure. There is no need to
replace xenstored or libxc when the real xenstored and libxc are
available.
> I'm looking very much forward to talking to you about this in Boston. Are you
> around already?
>
Yep!
- [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, (continued)
- Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Stefano Stabellini, 2010/11/02
- Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Paolo Bonzini, 2010/11/02
- Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Gerd Hoffmann, 2010/11/02
- Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Paolo Bonzini, 2010/11/02
- Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Stefano Stabellini, 2010/11/02
- Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn, Alexander Graf, 2010/11/02
- Re: [Qemu-devel] Re: [PATCH 28/40] xenner: libxc emu: evtchn,
Stefano Stabellini <=
[Qemu-devel] [PATCH 29/40] xenner: libxc emu: grant tables, Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 17/40] xenner: kernel: Main (x86_64), Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 01/40] elf: Move translate_fn to helper struct, Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 13/40] xenner: kernel: Headers, Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 12/40] xenner: kernel: Hypercall handler (generic), Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 20/40] xenner: kernel: mmu support for 32-bit PAE, Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 22/40] xenner: kernel: mmu support for 64-bit, Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 15/40] xenner: kernel: lapic code, Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 27/40] xenner: add xc_dom.h, Alexander Graf, 2010/11/01
[Qemu-devel] [PATCH 34/40] xenner: PV machine, Alexander Graf, 2010/11/01