Re: [Xen-devel] [PATCH v2 11/22] xen/x86: allow disabling emulated devices for HVM guests

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 07/02/2015 07:49 AM, Stefano Stabellini wrote:
> On Wed, 1 Jul 2015, Andrew Cooper wrote:
> > On 01/07/15 17:13, Stefano Stabellini wrote:
> > > 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.
> > Not in the slightest.  It is *exactly* the same as existing hardware
> > virt.
> I thought we were speaking about emulation, specifically regarding
> device emulation in Xen x86, such as the hpet for example. In this
> context APICV is a bit of a special case. Are there other devices being
> partially virtualized in hardware on x86? (I admit that I haven't follow
> x86 development that closely.)
>
>
> > Hardware does most of the work, but occasionally needs to break
> > into Xen to mange thing.  The difference is that we don't call some of
> > the existing vmexits "emulating an x86 cpu", despite this being what is
> > actually happening.
> To me, that is different.
>
>
> > > But in general, considering that the whole purpose of PVH as DomU is
> > > security
From kernel perspective, the major reason for having PVH is to move 
away from PV memory management (in the long term)

-boris


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel