On 01/07/15 16:51, Boris Ostrovsky wrote: > On 07/01/2015 11:46 AM, Andrew Cooper wrote: >> On 01/07/15 15:46, Roger Pau Monne wrote: >>> Introduce a new DOMCTL flag that can be used to disable device >>> emulation >>> inside of Xen for HVM guests. The following emulated devices are >>> disabled >>> when the XEN_DOMCTL_CDF_noemu is used: hpet, pmtimer, rtc, ioapic, >>> lapic, >>> pic and pmu. Also all the MMIO handlers are disabled. >>> >>> Signed-off-by: Roger Pau Monné <roger....@citrix.com> >>> Cc: Jan Beulich <jbeul...@suse.com> >>> Cc: Andrew Cooper <andrew.coop...@citrix.com> >>> Cc: Boris Ostrovsky <boris.ostrov...@oracle.com> >>> Cc: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> >>> Cc: Aravind Gopalakrishnan <aravind.gopalakrish...@amd.com> >>> Cc: Jun Nakajima <jun.nakaj...@intel.com> >>> Cc: Eddie Dong <eddie.d...@intel.com> >>> Cc: Kevin Tian <kevin.t...@intel.com> >> I would be hesitant to have a blanket change like this. >> >> Consider APICV/AVIC. For performance reasons, we absolutely want HVM >> and PVH to make use of them, as they are substantially more efficient >> using hardware support than evening using plain evtchn hypercalls. >> >> However, the flipside is that we must provide an LAPIC emulation to >> cover the bits which hardware cannot virtualise. >> >> As a random idea, how about having a new hypercall or hvmparam which >> provides a bitmap of permitted emulators? This would allow far finer >> grain control over what is and isn't available to a domain. > > I think we also need to decide on which subsets of emulators we are > going to support, otherwise test matrix will become pretty big. For > example, initially we may want to allow all (for what we now call HVM) > or none (PVH).
Right, but that can currently be enforced with an "if ( arg != 0 && arg != ~0 ) return -EOPNOTSUPP;" in the hypercall handler for now. It still leaves us with the ability to add in LAPIC emulation in the future by changing the auditing. A blanket "no emulation" boolean is very much harder to relax in the future. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
