Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes
> On 12 Apr 2018, at 08:32, George Dunlapwrote: > > > >> On Apr 12, 2018, at 2:18 AM, Chao Gao wrote: >> >> On Wed, Apr 11, 2018 at 05:10:40PM +, Lars Kurth wrote: >>> ## Longer Term - Agreed to Pause >>> >>> ### [PATCH v4 00/28] add vIOMMU support with irq remapping function of >>> ### virtual VT-d >>> >>> Sent in for meeting agenda by George >>> v3 posted by Lan Tianyu on 22 September 2017: marc.info/?l=xen-devel= >>> v4 posted by Chao Gao: https://xen.markmail.org/thread/wfyorbn3nzsio6s >>> **Seems to have had review by Roger Pau Monne (1 ACK) >>> No issues** >>> Primarily needs George as reviewer >>> Agreed to park this, because NVDIMM work is more important >> >> I want to clarify that I will continue to working on this, i.e. send out >> patches and respond to comments. "Pause" here only means review will be >> paused because George and Roger who are willing to review this series >> have to finish NVDIMM work first. > > Er, I think this comment was misplaced — it was the SPP series that I need to > be the primary reviewer on. I wasn’t aware that the vIOMMU series had > anything specific to do with the mm code. I may have recorded this incorrectly in that Royger would be the primary reviewer. I can't recall. In any case, the effect is the same, as Royger is also on the critical path for NVDIMM @John, @Chao: I agree with your clarification: that is what I meant. I recorded it inaccurately. As an aside, I will take the replies to this thread and copy it into the google doc (but I won't send out PDFs for it) Regards Lars___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes
> On Apr 12, 2018, at 2:18 AM, Chao Gaowrote: > > On Wed, Apr 11, 2018 at 05:10:40PM +, Lars Kurth wrote: >> ## Longer Term - Agreed to Pause >> >> ### [PATCH v4 00/28] add vIOMMU support with irq remapping function of >> ### virtual VT-d >> >> Sent in for meeting agenda by George >> v3 posted by Lan Tianyu on 22 September 2017: marc.info/?l=xen-devel= >> v4 posted by Chao Gao: https://xen.markmail.org/thread/wfyorbn3nzsio6s >> **Seems to have had review by Roger Pau Monne (1 ACK) >> No issues** >> Primarily needs George as reviewer >> Agreed to park this, because NVDIMM work is more important > > I want to clarify that I will continue to working on this, i.e. send out > patches and respond to comments. "Pause" here only means review will be > paused because George and Roger who are willing to review this series > have to finish NVDIMM work first. Er, I think this comment was misplaced — it was the SPP series that I need to be the primary reviewer on. I wasn’t aware that the vIOMMU series had anything specific to do with the mm code. -George ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes
Agree with Chao. This is more accurate statement. We have spent lots of effort on adding vIOMMU support with irq remapping and should continue after George wraps up vNVDIMM design discussions with us in this short period. Best Regards John Ji -Original Message- From: Gao, Chao Sent: Thursday, April 12, 2018 9:19 AM To: Lars Kurth <lars.ku...@citrix.com> Cc: Ji, John <john...@intel.com>; George Dunlap <dunl...@umich.edu>; Peng, Chao P <chao.p.p...@intel.com>; Juergen Gross <jgr...@suse.com>; Tamas K Lengyel <ta...@tklengyel.com>; Wei Liu <wei.l...@citrix.com>; Andrew Cooper <andrew.coop...@citrix.com>; Daniel Kiper <daniel.ki...@oracle.com>; Roger Pau Monné <roy...@freebsd.org>; Christopher Clark <christopher.w.cl...@gmail.com>; Janakarajan Natarajan <jnata...@amd.com>; Rich Persaud <pers...@gmail.com>; Paul Durrant <paul.durr...@citrix.com>; committ...@xenproject.org; Jan Beulich' <jbeul...@suse.com>; xen-devel <xen-devel@lists.xenproject.org>; Brian Woods <brian.wo...@amd.com> Subject: Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes On Wed, Apr 11, 2018 at 05:10:40PM +, Lars Kurth wrote: >## Longer Term - Agreed to Pause > >### [PATCH v4 00/28] add vIOMMU support with irq remapping function of >### virtual VT-d > >Sent in for meeting agenda by George >v3 posted by Lan Tianyu on 22 September 2017: >marc.info/?l=xen-devel= >v4 posted by Chao Gao: https://xen.markmail.org/thread/wfyorbn3nzsio6s >**Seems to have had review by Roger Pau Monne (1 ACK) No issues** >Primarily needs George as reviewer Agreed to park this, because NVDIMM >work is more important I want to clarify that I will continue to working on this, i.e. send out patches and respond to comments. "Pause" here only means review will be paused because George and Roger who are willing to review this series have to finish NVDIMM work first. Thanks Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes
On Wed, Apr 11, 2018 at 05:10:40PM +, Lars Kurth wrote: >## Longer Term - Agreed to Pause > >### [PATCH v4 00/28] add vIOMMU support with irq remapping function of >### virtual VT-d > >Sent in for meeting agenda by George >v3 posted by Lan Tianyu on 22 September 2017: marc.info/?l=xen-devel= >v4 posted by Chao Gao: https://xen.markmail.org/thread/wfyorbn3nzsio6s >**Seems to have had review by Roger Pau Monne (1 ACK) >No issues** >Primarily needs George as reviewer >Agreed to park this, because NVDIMM work is more important I want to clarify that I will continue to working on this, i.e. send out patches and respond to comments. "Pause" here only means review will be paused because George and Roger who are willing to review this series have to finish NVDIMM work first. Thanks Chao ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] X86 Community Call: Wed March 14, 15:00 - 16:00 UTC - Meeting Minutes
On 04/11/2018 08:10 PM, Lars Kurth wrote: > ### [PATCH RFC 00/14] EPT-Based Sub-page Write Protection Support > > ### (Zhang Yi) > > RFC posted by Zhang Yi Oct 19, 2017 > https://marc.info/?l=xen-devel= > https://xen.markmail.org/thread/m75h6b2aiwk5h7fx > > > No acks, reviews only by memaccess maintainers / developers > Issues: Use case for the feature is still not clear and needs discussion > Lars: who needs to review? > Andrew: mainly George, Tamas, Razvan - major changes to ept2pm structure > (different > page table structure) and Andrew. > Andrew: did take a quick look. Nothing egregious in it. Did not have a lot of > free time to look > at it. > George: was going to look at it, but focus on NVDIMM first and EPT stuff > second. > Tamas: provides write protection on the sub-page - my tools don't have a > use-case for this. > Also not sure how this would integrate into alt2pm. Razvan may have a > use-case. > Andrew: no interaction with alt2pm, write protection 128 byte aligned > granularity instead of > 4K for write tracking a substructure within a page > Zhang Yi: I have a change in the patch which he wants to look at > George: can look at modifying that or store the type information elsewhere > Andrew: Have to shuffle the bits in the EPT tree > Summary: the issue isn’t really about use-cases, but primarily about > prioritizing George’s > bandwidth > **ACTION (April):** Andrew will poke Razvan (give some indication interface > ios going) > **ACTION (April):** George will pick this up after NVDIMM has made some > progress Indeed we do have use cases for this and are very interested in the feature. As you might expect, this is about optimizing: in several cases we're only interested in a narrow part of a page, but need to set restrictions on 4096 bytes - this causes needless page fault exits / mem_access events. It would indeed need to play well with altp2m to be as useful as possible. Our use case for altp2m (assuming a stable altp2m - I'm still debugging the logdirty VGA issue) is to use it for 1) the cases where the emulator doesn't know an instruction that has caused a page fault (in which case we get an UNIMPLEMENTED vm_event), and 2) as a workaround for a interrupt race issue that can happen with emulation. 2) is hopefully a temporary problem, 1) is probably not - new instructions do appear with new hardware. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel