[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

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
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.