Re: [Xen-devel] Re: [Qemu-devel] [PATCH 1/7] xen: groundwork for xen support

[Anthony Liguori <anthony@codemonkey.ws>]

Gerd Hoffmann wrote:
> Anthony Liguori wrote:
>   
>> map-cache is one of those things I don't expect to ever get merged.
>>     
>
> And the need for that will go away over time IMHO.  If your Dom0 is
> 64bit you have no address space pressure and thus no need for mapcache.
>  Given we have 32-on-64 and non-PAE Xen is depricated anyway there is
> almost no reason to not run 64bit Xen and Dom0.
>   

Right.

>> Ideally, I'd like to see Xen/KVM integration look like this:
>>
>> 1) Xen support is detected in configure (libxc et al) and conditionally
>> enabled.
>> 2) When running on bare metal, detect whether KVM acceleration is
>> available, also detect if kqemu acceleration is available
>> 3) When running under Xen, detect that Xen is available, and create a
>> full virt domain
>> 4) If a user specifies a type=xen device, it should Just Work provided
>> you are in a Xen environment (erroring appropriately)
>> 5) A user can explicitly specify -M xenpv.  If running under Xen, this
>> would create a Xen PV guest.  If running on bare metal, Xenner would be
>> used to present a Xen shim layer.  This should work with KVM
>> acceleration or without KVM acceleration.  Bonus points if it works with
>> kqemu too.
>>     
>
> I'm surprised how well you can read my mind.
>   

Scary, huh? :-)

> Yes, I wanna have the bonus points ;)
>
> There are two additional points you didn't see though:
>
> For (3) and (5) qemu should support two modes:  First, attach to an
> existing domain.  This is how Xen works today.  And we want get rid of
> the qemu-dm fork, right?  Second, optionally also create the domain,
> like Xenite.
>   

I have mixed feelings about this, but I don't think there's a way to 
support stub domains without this functionality.  Obviously, when you 
run QEMU within a stub domain, the guest domain has already been 
created.  Well, maybe it doesn't have to be that way but it seems most 
reasonable to do it that way.

> (4) should also just work when you are *not* in a Xen environment[1]
>   

I considered suggesting that but figured it would be too much.  I should 
have figured it was already working in some form :-)

So how does the upstream Xen community feel about all of this?  Is this 
a reasonable approach to merging Xen functionality into QEMU?

Regards,

Anthony Liguori

> cheers,
>   Gerd
>
> [1]  It actually does, btw.  Code isn't ready yet for merging.
>      Stay tuned ;)
>
>