From: Wei Liu <wei.liu2@citrix.com>
To: "Wu, Feng" <feng.wu@intel.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
"wei.liu2@citrix.com" <wei.liu2@citrix.com>,
George Dunlap <george.dunlap@eu.citrix.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"Wang, Yong Y" <yong.y.wang@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
"Jan Beulich (JBeulich@suse.com)" <JBeulich@suse.com>,
"Zhang, Yang Z" <yang.z.zhang@intel.com>
Subject: Re: Requesting for freeze exception for VT-d posted-interrupts
Date: Mon, 13 Jul 2015 12:00:41 +0100 [thread overview]
Message-ID: <20150713110041.GD4108@zion.uk.xensource.com> (raw)
In-Reply-To: <E959C4978C3B6342920538CF579893F002608531@SHSMSX104.ccr.corp.intel.com>
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@intel.com>
>
> [v3 02/15] Add helper macro for X86_FEATURE_CX16 feature detection
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>
> [v3 04/15] iommu: Add iommu_intpost to control VT-d Posted-Interrupts feature
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
>
> [v3 06/15] vmx: Extend struct pi_desc to support VT-d Posted-Interrupts
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Acked-by: Kevin Tian <kevin.tian@intel.com>
>
> [v3 07/15] vmx: Initialize VT-d Posted-Interrupts Descriptor
> Acked-by: Kevin Tian <kevin.tian@intel.com>
>
> [v3 09/15] vt-d: Extend struct iremap_entry to support VT-d Posted-Interrupts
> Acked-by: Kevin Tian <kevin.tian@intel.com>
>
> [v3 10/15] vt-d: Add API to update IRTE when VT-d PI is used
> Acked-by: Kevin Tian <kevin.tian@intel.com>
>
> [v3 13/15] vmx: Properly handle notification event when vCPU is running
> Acked-by: Kevin Tian <kevin.tian@intel.com>
>
> [v3 14/15] Update Posted-Interrupts Descriptor during vCPU scheduling
> Acked-by: Kevin Tian <kevin.tian@intel.com>
>
> [v3 15/15] Add a command line parameter for VT-d posted-interrupts
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
>
> 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
next prev parent reply other threads:[~2015-07-13 11:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-13 6:55 Requesting for freeze exception for VT-d posted-interrupts Wu, Feng
2015-07-13 9:05 ` Jan Beulich
2015-07-13 11:00 ` Wei Liu [this message]
2015-07-14 5:51 ` Wu, Feng
2015-07-14 9:21 ` Wei Liu
2015-07-14 10:09 ` Jan Beulich
2015-07-14 14:17 ` Wei Liu
2015-07-14 14:46 ` Jan Beulich
2015-07-14 15:02 ` Wei Liu
2015-07-14 16:01 ` Jan Beulich
2015-07-15 15:46 ` Wei Liu
2015-07-15 22:48 ` Wu, Feng
2015-07-17 9:28 ` Wei Liu
2015-07-13 15:38 ` Dario Faggioli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150713110041.GD4108@zion.uk.xensource.com \
--to=wei.liu2@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=feng.wu@intel.com \
--cc=george.dunlap@eu.citrix.com \
--cc=kevin.tian@intel.com \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
--cc=yong.y.wang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.