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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

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 ;)
>
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel