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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jul 14, 2015 at 05:51:02AM +0000, Wu, Feng wrote:
> 
> 
> > -----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?
> 

Note that I'm not the only one who makes the decision and I can't speak
for maintainers. The first thing you ought to do is to convince
maintainers, not me.

If you ask for my opinion -- I don't see a point in releasing feature
with security flaw in design, even if it is off by default. 

Wei.

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