From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH RFC v13 03/20] Introduce pv guest type and has_hvm_container macros Date: Thu, 26 Sep 2013 17:24:50 +0100 Message-ID: <20130926162450.GM54428@ocelot.phlegethon.org> 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 , Jan Beulich , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org At 14:46 +0100 on 26 Sep (1380206764), George Dunlap wrote: > 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. True. And I suspect with various patchsets around that allow for multiple ioreq-servicing backends we can allow for there to be none. > Having the PV e820 map makes sense, but you can file that under "make > available to hvm guests as well". > > 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. I would be inclined to use the HVM paths for PIO and emulated ops; the cpuid interface might need fudging, I guess. > The other big thing is being able to set up more state when bringing up > a vcpu. Sure. But again, probably OK to expose a fuller setvcpucontext to all HVM guests. > 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. That's a fair point. Could we arrange that by having control flags flags for things like RTC and [[IO]A]PIC, the way we do for HPET? The same argument goes the other way -- might we want to have a HVM param that disables the extended PV interface? We haven't done that before (except, I guess, for the Viridian interface), but it would be easy enough to arrange, and it seems less intrusive than having a third class of guests at the top level. Tim.