qemu-devel
[Top][All Lists]
Advanced

[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!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]