From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH RFC v13 03/20] Introduce pv guest type and has_hvm_container macros Date: Thu, 26 Sep 2013 11:31:02 -0400 Message-ID: <20130926153101.GE6538@konrad-lan.dumpdata.com> References: <1379955000-11050-1-git-send-email-george.dunlap@eu.citrix.com> <1379955000-11050-4-git-send-email-george.dunlap@eu.citrix.com> <20130926115359.GC54428@ocelot.phlegethon.org> <52443A9C.3080602@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <52443A9C.3080602@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Keir Fraser , Tim Deegan , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Thu, Sep 26, 2013 at 02:46:04PM +0100, George Dunlap wrote: > On 26/09/13 12:53, Tim Deegan wrote: > >Hi, > > > >At 17:49 +0100 on 23 Sep (1379958583), George Dunlap wrote: > >>The goal of this patch is to classify conditionals more clearly, as to > >>whether they relate to pv guests, hvm-only guests, or guests with an > >>"hvm container" (which will eventually include PVH). > > - speculative wombling begins - > > > >Reading this for the (apparently) 13th time, it strikes me that this > >distinction feels wrong, like entities are being multiplied beyond > >necessity. > > > >A PVH guest is basically a HVM guest that starts with paging enabled and > >uses event channel instead of virtual APIC. > > > >I'm not sure this needs any special treatment from Xen. We can supply a > >PVH guest with an APIC and if it never uses it, fine. And we can supply > >all HVM guests with any extra hypercalls that PVH needs (for vcpu > >bringup &c). Things like not having a qemu process to serve ioreqs can > >be arranged by the toolstack. > > > >This is from a position of ignorance, of course, and I'm happy to be > >corrected by the people who've actually been hacking on the code. > > As I've been putting the series together, I've wondered the same myself. > > There's more to not having a qemu than just not starting qemu, of > course; a lot of the HVM codepaths assume that there is one and will > dereference structures which will be empty. But that should be > fairly easy to fix. > > Having the PV e820 map makes sense, but you can file that under > "make available to hvm guests as well". Which I think Mr. Gordon (sp?) had been doing for some of the PCI NVidia passthrough stuff. Basically making e820_host work for HVM guests. > > The main things left are the PV paths for cpuid, PIO, and forced > emulated ops. I haven't taken a close look at how these differ, or > what benefit is gained from using the PV version over the HVM > version. > > The other big thing is being able to set up more state when bringing > up a vcpu. > > One reason to disable unneeded things is the security angle: there > is a risk, no matter how small, that there is somehow an exploitable > bug in our emulated APIC / PIT code; so running with the code > entirely disabled is more secure than running with it enabled but > just not used. > > But it's possible that we could just add a few options to the > existing "HVM mode" that would implement all of this. > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel