Re: [Xen-devel] Requesting for freeze exception for VT-d posted-interrupts

["Wu, Feng" <feng.wu@xxxxxxxxx>]

> -----Original Message-----
> From: Wei Liu [mailto:wei.liu2@xxxxxxxxxx]
> Sent: Monday, July 13, 2015 7:01 PM
> To: Wu, Feng
> Cc: wei.liu2@xxxxxxxxxx; xen-devel@xxxxxxxxxxxxx; Jan Beulich
> (JBeulich@xxxxxxxx); andrew.cooper3@xxxxxxxxxx; George Dunlap; Tian, Kevin;
> Zhang, Yang Z; Wang, Yong Y
> Subject: Re: Requesting for freeze exception for VT-d posted-interrupts
> 
> On Mon, Jul 13, 2015 at 06:55:30AM +0000, Wu, Feng wrote:
> > Hi maintainers,
> >
> > We would like to request an extension for freeze exception for VT-d
> posted-interrupts patch-set.
> >
> > 1. clarify the state of patch series / feature.
> > [v3 01/15] Vt-d Posted-interrupt (PI) design
> > Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 02/15] Add helper macro for X86_FEATURE_CX16 feature detection
> > Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> > Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >
> > [v3 04/15] iommu: Add iommu_intpost to control VT-d Posted-Interrupts
> feature
> > Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 06/15] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts
> > Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> > Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 07/15] vmx: Initialize VT-d Posted-Interrupts Descriptor
> > Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 09/15] vt-d: Extend struct iremap_entry to support VT-d
> Posted-Interrupts
> > Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 10/15] vt-d: Add API to update IRTE when VT-d PI is used
> > Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 13/15] vmx: Properly handle notification event when vCPU is running
> > Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling
> > Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > [v3 15/15] Add a command line parameter for VT-d posted-interrupts
> > Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> >
> > 2. explain why it needs to be in this release (benefits).
> > VT-d posted-interrupts is an important interrupt virtualization feature for
> > device pass-through, the running guest can handle external interrupts
> > in non-root mode, hence it can eliminate the VM-Exits caused by external
> > interrupts. Please refer to the design doc:
> > http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg03691.html
> >
> > >From our experimental environment, after using VT-d posted-interrupts, we
> > measured 25% improvement in transaction rate netperf TCP_RR benchmark
> > and 28% reduction in host CPU utilization when using assigned devices.
> > (10G NIC in my test).
> >
> > 3. explain why it doesn't break things (risks).
> > This feature only exists in Broadwell Server platform, it has no effect on 
> > the
> > current hardware.
> >
> 
> You miss the part that how much common code it touches. There is still
> risk of breaking VMX and VT-D even if PI is disabled.
> 
> > 4. CC relevant maintainers and release manager.
> > Done
> >
> > There are two main outstanding issues so far:
> > 1. Jan's security concern. I have proposed some solutions but Jan still has
> > some problems with my proposals. It would be great if Jan can give a clear
> > proposal so that we can discuss and keep making progress.
> > 2. Scheduler issue: there are conflicts among maintainers Jan/George/Dario.
> > I would agree with Jan's suggestion below:
> >
> > " Doing this in a central place is certainly the right approach, but
> > adding an arch hook that needs to be called everywhere
> > vcpu_runstate_change() wouldn't serve that purpose. Instead
> > we'd need to replace all current vcpu_runstate_change() calls
> > with calls to a new function calling both this and the to be added
> > arch hook."
> >
> 
> Given the current time scale now, I think it would be very hard to get
> these two concerns addressed within a week. Xen has always taken
> security serious, I don't want to rush in a feature with possible flawed
> design.
> 
> My answer to this request is no until these concerns are addressed.

Is it possible to get to 4.6 if making this feature default off?

Thanks,
Feng

> 
> > However, if different maintainers still hold different opinions, I would
> appreciate
> > it if maintainers can reach consensus among themselves so that we can keep
> > making progress
> >
> 
> Yes, this is fore sure. This is what we need to do to work as a
> community whether this feature is aimed for 4.6 or not.
> 
> Wei.
> 
> > Thanks,
> > Feng

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