[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests
On Wed, 1 Jul 2015, Andrew Cooper wrote: > 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.pau@xxxxxxxxxx> > >>> Cc: Jan Beulich <jbeulich@xxxxxxxx> > >>> Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> > >>> Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> > >>> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx> > >>> Cc: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@xxxxxxx> > >>> Cc: Jun Nakajima <jun.nakajima@xxxxxxxxx> > >>> Cc: Eddie Dong <eddie.dong@xxxxxxxxx> > >>> Cc: Kevin Tian <kevin.tian@xxxxxxxxx> > >> 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. APICV is a bit of a special case, because it is partially virtualized in hardware. But in general, considering that the whole purpose of PVH as DomU is security, as a Xen user, I would not want any emulators running with PVH guests. Otherwise I might as well run PV on HVM. Being able to enable/disable specific emulators sounds more future proof, but in practice it is likely to lead to many broken non default configs. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |