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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

> 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