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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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
>
> Says who?  An entirely reasonable alternate opinion is "HVM without the
> emulation overhead".

I say that :-)

I don't want to diminish the value of PVH. It is indeed very valuable
and some people might agree with your statement. However I am trying to
establish few clear use cases that, as Xen Project, we do support well,
rather than trying to be everything to everybody. I wouldn't want to
find ourselves into a situation similar to stubdom in a few years from
now with PVH too.

I think we should consider our current test matrix, realize that is way
too large for our current level of engagement, and try to decrease it,
rather than increasing it.


> > , as a Xen user, I would not want any emulators running with PVH
> > guests. Otherwise I might as well run PV on HVM.
>
> That is fine from a security point of view, but is not shared by most
> users Xen.
>
> Most users of Xen want to squeeze every ounce of performance out of the
> hardware they paid $$$ for, and won't mind exposing an LAPIC
> implementation to a PVH guest, seeing as the same implementation is
> available to windows or existing PVHVM guests.

Sure, in that case let's make a choice and enable the vLAPIC for PVH by
default. Why do we need to make it configurable? Why do we need 2
configurations instead of 1? We cannot always be everything to
everybody.


> (when eventually supported), offering host administrators a choice
> between more security or more performance is perfectly ok, but designing
> PVH to be secure at the deliberate detriment of performance is unacceptable.

It is never that simple.

If we have 2 configs for PVH, then we need two set of tests in OSSTest,
that are going to cost time to write and resources to run. As you
probably know we already have too many. They are going to require more
hardware in the Xen Project test infrastructure and eventually more
people to maintain it.

If we have 2 configs for PVH, we have two code paths to maintain in Xen
and Linux.  Are you up for taking up maintenance of PVH in both
configurations?

If we have 2 configs for PVH, the next time somebody wants to make an
improvement for it, she needs to take care of both cases and test her
patches twice. Overall it is going to be more expensive.

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