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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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@citrix.com>
>>>>>>> Cc: Jan Beulich <jbeulich@suse.com>
>>>>>>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>>>>>>> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>>>>>>> Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>>>>>> Cc: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@amd.com>
>>>>>>> Cc: Jun Nakajima <jun.nakajima@intel.com>
>>>>>>> Cc: Eddie Dong <eddie.dong@intel.com>
>>>>>>> Cc: Kevin Tian <kevin.tian@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.
>>> 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@lists.xen.org
http://lists.xen.org/xen-devel